lmm parent
Why would you use UUIDv7 rather than UUIDv4 though?
UUIDv4 is much more scattered (i.e., uniformly distributed), which heavily degrades indexing performance in databases.
But mainly on writes, not much for reads.
And if your database is 99% reads 1% writes, the difference probably doesn't really matter.
And tons of database indexes operate on randomly distributed data -- looking up email addresses or all sorts of things. So in many cases this is not an optimization worth caring about.
This depends on the database and should not be written as gospel.
Which databases doesn't it degrade performance with when used as an indexed field?
UUIDv7 seems popular for Postgres performance improvements, but it causes issues with databases like Spanner.
https://medium.com/google-cloud/understanding-uuidv7-and-its...
Lots of distributed, NoSQL databases work (or partially work) this way too (e.g., HBase rowkey, Accumulo row ID, Cassandra clustering key, DynamoDB sort key). They partition the data into shards based upon key ranges and then spread those shards across as many servers as possible. UUIDv7 is (by design) temporally clustered. Since many workloads place far more value on recent data, and all recent data is likely to end up in the same shard, you bottleneck on the throughput of a single server or, even with replication, a small number of servers.