alt Hacker NewsUUIDv7 is not that useful. I'm still using mostly UUIDv4 and UUIDv5.
I'm leaning increasingly heavily on v5 for its determinism which is extremely important for IDs. I would sacrifice every other property to get determinism.
You can't have idempotency without determinism and you can't get reliability without idempotency.
Once you factor in failure and retry scenarios under concurrency, you often need ID determinism. In the rare cases I don't want determinism, I prefer to go all-in on randomness. I prefer my IDs to be well spread out; it scales better, more predictable, less of a security liability (prefer not to have all data clustered in the same place)...
Both UUIDv4 and UUIDv5 outputs are uniformly distributed. IMO this is a desirable property which is well worth a bit of additional compute. v7 feels like an optimization hack, and it comes at a cost.
If you want to get the performance benefits of v7 with the determinism of v5, then you need to have essentially two IDs; the id (v7) and an idempotency key (which is essentially like a second ID you have to maintain; e.g. UUIDv5)... In the end, maintaining a UUIDv7 ID + idempotency key is less performant than just having a single UUIDv5 id which does both jobs for no extra effort... Not to mention, less maintainable and more complicated to use.
Replies
Hey author here, thanks for reading the post. I haven't seen UUIDv5 used very often but I'll have to think about the idempotency angle more.
One thing that concerns me is that UUIDv5 is based on SHA1, which is an insecure hashing algorithm. I generated a pair of colliding UUIDv5s in an earlier post in this series (https://alexsci.com/blog/uuid-oops/#insecure-hash-functions). So I don't think you can use UUIDv5 for security critical functions.
> You can't have idempotency without determinism
You absolutely can. The idempotency nonce must be generated by the client who is responsible for firing potential retries. And a random UUIDv4 is a perfectly fine nonce.
If the client _doesn't_ generate a nonce, it doesn't matter what the server side does, they cannot tell from the request data if it's supposed to be a retry or a new request with the same data. A hash such as a UUIDv5 is more performant but not logically any better than comparing the raw data of the two requests. If you use that UUIDv5 as your primary key for insert/update, it's little more than a natural key, with all its well-known drawbacks.