UUID Generator

A UUID is a 128-bit number, written as 32 hexadecimal digits in five hyphen-separated groups: 8-4-4-4-12. The layout is not decoration — it encodes two fields that make the value self-describing.

The first digit of the third group is the version. For a version 4 UUID it is always 4. The first digit of the fourth group encodes the variant, and is always one of 8, 9, a or b. Those six bits are fixed by the format, which leaves 122 bits of actual randomness.

That is the whole definition. A version 4 UUID carries no timestamp, no machine identifier and no sequence number. Two UUIDs generated on the same machine in the same millisecond are unrelated — the only thing that could ever link them is chance.

Because the version and variant digits are fixed, a v4 UUID is not a uniformly random 128-bit string. If you need every bit to be random, generate 16 random bytes and hex-encode them instead; do not use a UUID.

With 122 random bits there are about 5.3 × 10^36 possible version 4 UUIDs. The birthday bound — the point at which a collision becomes as likely as not — is around 2.7 × 10^18 values.

Put another way: you would have to generate one billion UUIDs every second for about 85 years before the chance of ever producing a duplicate reached 50%. For the lifetime of any application you are likely to write, treating v4 UUIDs as unique is safe.

The failure mode to actually worry about is not collision, it is duplication of a different kind: copying a row, re-running a seeding script, or restoring a database snapshot can produce two records with the same UUID. That is a data problem, not a randomness problem, and no generator can protect you from it.

They are the same thing. GUID — globally unique identifier — is the name Microsoft uses for the same 128-bit format, and a "GUID" from SQL Server, C# or COM interoperates with a "UUID" from PostgreSQL, Python or a REST API without any conversion beyond case and hyphens.

The format is standardised in three places that all agree: RFC 4122 and its 2024 replacement RFC 9562, ISO/IEC 9834-8, and ITU-T X.667. So the choice of word is purely a matter of which ecosystem you are reading.

This is the most expensive thing people get wrong about version 4 UUIDs, and it has nothing to do with collisions.

A clustered index — the default in MySQL InnoDB, and what a primary key becomes in SQL Server unless you say otherwise — stores rows in the order of the key. Sequential integer keys append to the end of the index, which is cheap. Random keys insert at a random position every time, which forces the engine to split pages, shuffle data and write to disk in scattered locations. Insert throughput drops and the index fragments.

There is a second cost: 128 bits instead of 32 or 64. Every secondary index carries a copy of the primary key, so the penalty is multiplied by the number of indexes on the table. On a large table this is measured in gigabytes.

Three ways out, in increasing order of effort. Use a sequential integer for the primary key and keep the UUID as a separate indexed column for external reference — the usual compromise. Use a UUID version that is time-ordered. Or, on PostgreSQL, accept the storage cost and use its native uuid type, which is stored as 16 bytes rather than the 36 of the text form.

The time-ordered option used to mean version 1 UUIDs, which leak the machine's MAC address and the generation timestamp. RFC 9562, published in May 2024, defines better answers: version 7 puts a 48-bit millisecond timestamp first and fills the rest with randomness, giving you sortability without exposing a MAC address. Version 6 is the same idea with the timestamp field reordered for lexicographic sorting.

If your database supports it, version 7 is usually the right default for a primary key today, and version 4 remains the right choice for an opaque identifier that is never used for ordering.

It is not a secret. A v4 UUID is unguessable in practice, but it is not a keyed or authenticated value: anyone who learns one knows it, and it cannot be revoked or rotated. Do not use a UUID as an API key, a password reset token or a session identifier — generate those with a purpose-built keyed generator instead.

It is not a hash. Generating the same UUID twice from the same input is impossible by design, so it cannot be used to detect duplicates or to fingerprint content.

It is not guaranteed unique. It is a probabilistic identifier whose collision chance is negligible, which is not the same as a database constraint. If two rows must not share an identifier, enforce that with a unique index rather than with statistics.

It carries no meaning. You cannot extract a creation time, a tenant or a shard from a version 4 UUID. If you need any of those, encode them deliberately in a version 8 UUID or keep them in separate columns where they are queryable.