Comment by tanin
13 hours ago
I generally avoid using UUID unless there's a strong reason for it.
I know the conventional wisdom says that the collisions are extremely rare <<insert some sort of cosmis analogy>>. Then, some reddit users reported encountering a collision: https://www.reddit.com/r/webdev/comments/1kvkxte/comment/mud...
Ultimately, we'd have to design the system to handle collision anyway. Might as well design a system to avoid collision in the first place. Then, if we have a system that avoids collision, then whether UUID is used is irrelevant.
UUID are amazing and should be the default primary key for pretty much anything. They can be independently generated and require no central shared location.
Until you have any reason to believe UUIDs (and not bugs or misunderstanding as the blog post) are the critical component in the system, just use them. Look at the odds for collision with properly a setup (ntp + any modern cpus) then look at odds for anything else being an issue.
You don't have to handle collisions and I don't believe that multiple Redditors have experienced this. If they have, it's an issue with the implementation and not UUIDs.
The math is simply not in there favor, by a number so large we cannot conceive of it in our tiny brains.
UUIDs have other useful properties. For example, they don't expose counts (e.g. how many customers you have.) They make URL / resource guessing impossible.
ids in the form of `[prefix]_[uuid stripped of dashes]` is ideal for most use cases. It should be the default the way Postgres is the default. Any deviation have good reason.
It’s not the default though is it. I wonder why?
The biggest advantage I've seen for UUID come with distributed systems imo. The ability to create an id without lock coordination allows for much easier horizontal scaling. UUIDv1 avoids the collision issue by using a portion of the MAC in the id, but v1-4 all have sorting issues. UUIDv7 is a good choice if your use case warrants it. If you can get away with a single integer field like a database primary key and not get bottlenecked that's much easier. When that doesn't work anymore one of the distributed id schemes like UUID are the only real options available.
Without that reddit user saying what kind of UUID or how it was generated, that anecdote is nearly useless.
> Ultimately, we'd have to design the system to handle collision anyway.
It's possible for a bug to create a collision. But it's also possible for a bug to return someone else's ID at any point in the process. So even if you try to "handle" collisions, it might not work. You can't programmatically detect a mistake like that. Detection only works for bugs in a narrow slice of the pipeline. And extra complication in the pipeline, especially with a code path that has never been taken before, adds its own risk and drops the trustworthiness of the entire system.
> Might as well design a system to avoid collision in the first place.
Agreed. But UUID accomplishes the goal of "designed to avoid collisions" by itself.
If there's a collision, just generate another uuid
It would be hard to know whether there is a collision at generation time. If you did know, it implies a lookup in a global database, then you are back where you started.
You don't have to. You can absorb the risk. Which most orgs do.