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.

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

You don't have to. You can absorb the risk. Which most orgs do.