UUID Generator

A version 4 UUID is 122 random bits, which is enough that collisions are not a practical concern — you can generate them independently on many machines with no coordination and never expect a clash. That independence is the point of the format, and it is why UUIDs are used where an auto-incrementing number would require a central authority to hand out.

Version 7 keeps the randomness but puts a millisecond timestamp in the leading 48 bits, so newly generated values sort after older ones. That matters for databases: a B-tree index takes inserts near the same leaf page cheaply, while random keys scatter writes across the whole index and force pages in and out of memory. The trade-off is that a v7 identifier reveals roughly when it was created, so v4 remains the right choice where that leak matters.

Common questions

Should I use v4 or v7?

Use v7 for anything stored as a database primary key, because time-ordered values keep index inserts clustered and avoid the write amplification that random keys cause. Use v4 when the identifier is public and its creation time should not be inferable, or when nothing about your storage benefits from ordering.

Can two UUIDs ever collide?

In practice, no. A v4 UUID contains 122 random bits, so the number of possible values is astronomically larger than the number anyone will generate. You would have to produce billions per second for many years before a collision became likely. This is what allows independent systems to mint identifiers without coordinating.

Why do random UUIDs hurt database performance?

Because a B-tree index stores keys in order. Sequential keys append to the same leaf page, which stays cached and writes cheaply. Random keys land anywhere, so each insert touches a different page, evicting others from memory and fragmenting the index. On a large table the difference in insert throughput is substantial, which is exactly what v7 was designed to fix.

Does a v7 UUID leak information?

It reveals approximately when it was created, since a millisecond timestamp occupies its leading bits. That is usually harmless for an internal record identifier and occasionally not — an identifier exposed publicly discloses signup or creation times, which can be enough to infer growth rates or ordering. Use v4 where that matters.