Is this a downside of UUID keys in general, or of using them as indexes? Would it be possible to create a primary index on a combination of inserted date and uuid and get opaque UUIDs and good indexing?
The alternative is having two required-unique columns only one of which is definitionally unique. It solves some problems and introduces others.
You can use UUIDv7 or ULID for that. One value with both the timestamp and random data inside.
Sorry, right; I meant that's the collation alternative to a multi-field record like v7.
Yes, it's a downside of using them in b-tree indexes. However, the purpose of having an ID is usually to use it for lookup (from foreign keys, query string arguments, ...). If you create an index on two columns, you won't be able to lookup using only the second value, at least not in Postgres.
That's interesting - I don't know enough about this! If it's lookup from a foreign key, won't it just go straight to the record? What's the index for there?