UUID Generator

········-····-····-····-············

What a version 4 UUID is

A version 4 UUID is almost entirely random: 122 of its 128 bits come from a random source, and the remaining six identify it as version 4. Nothing about where or when it was made is recorded in it, which is exactly why it is the default choice.

The odds of two independently generated version 4 UUIDs colliding are small enough to ignore in practice. That is what lets separate services mint identifiers without ever talking to one another.

When it is the right choice

Reach for version 4 whenever you need an identifier that carries no meaning and no coordination: a request id, an idempotency key, a record that will never be sorted by the identifier itself.

When to prefer something else

Because the values are random, consecutive inserts land in unrelated places in a B-tree index. On a busy table that fragments the index and makes it larger than it needs to be. If you are generating a primary key under load, a time-ordered version 7 UUID keeps the inserts together while staying just as unique.

Randomness is also the wrong tool when the identifier has to follow from something rather than be assigned to it. Where two systems must arrive at the same identifier for the same thing without ever talking to one another, a name-based version 5 UUID derives it from a namespace and a name instead.