Every developer has copied a UUID like 3f8a2c1e-9b4d-4e7a-a1b2-c3d4e5f6a7b8 into a schema without thinking twice. But UUIDs come in multiple versions with very different properties, and choosing the wrong one quietly degrades database performance at scale. Here is what actually matters.
What a UUID really is
A UUID (Universally Unique Identifier) is a 128-bit value defined by RFC 9562 (formerly RFC 4122). The canonical text form groups the 16 bytes into 8-4-4-4-12 hex digits. Those 128 bits are not all random — several bits encode the version (which generation scheme was used) and a variant field. When you see a 4 in the third group and an 8, 9, a, or b starting the fourth group, you are looking at a version-4, RFC-variant UUID.
The version lineup
v1 — time + MAC address. The original scheme embeds a timestamp and the machine’s MAC address. It is sortable by creation time, but it leaks the generating machine’s identity, which is a privacy problem in untrusted hands. Rarely a good default today.
v4 — random. 122 of the 128 bits come from a cryptographically secure random source. Nothing about the ID reveals when or where it was made. This is the everyday default, and what our UUID Generator produces.
v7 — time-ordered random. A 2024 standard that puts a millisecond Unix timestamp in the top bits, then fills the rest with random bytes. You get v4-style unpredictability plus approximate sortability.
v3/v5 — name-based. Deterministically hashed from a namespace and a name (MD5 for v3, SHA-1 for v5). The same input always yields the same UUID. Useful when you need an ID that is reproducible — for example, deriving a stable identifier from an external key.
How unique is “unique”, really?
A v4 UUID carries 122 random bits. The often-quoted math: after generating about 2.7 quintillion (2⁶¹) UUIDs, the probability of a single collision is still only around one in a billion. No production system has ever been threatened by accidental v4 collisions. When people say “UUIDs collide”, they are almost always describing a bug — reusing a broken random source, or truncating the ID — not the math.
The database index problem
This is where version choice stops being trivia. Most databases (MySQL InnoDB, SQL Server) cluster table rows physically by primary key. A random v4 key means every insert lands at an unpredictable page, causing:
- Page splits in already-full 16 KB InnoDB pages, fragmenting the index
- A bloated buffer pool, because the working set of “recently touched pages” is now the whole index
- Write amplification from redo logging every split
Benchmarks routinely show v4 primary keys inserting several times slower than monotonic keys on large InnoDB tables. Two fixes:
- Use v7 (or ULID) — time-ordered, so inserts are append-mostly and pages fill sequentially.
- Keep an auto-increment internal key and store the UUID as a secondary unique column, exposing only the UUID externally so IDs can be generated by any node without coordination.
Practical rules of thumb
- Public-facing identifiers: UUID (v4/v7). Sequential integers leak business volume — competitors can scrape your order counts from IDs alone.
- Database primary keys at scale: v7 or auto-increment; avoid raw v4 on clustered indexes.
- Idempotency keys and deduplication: v4 is perfect — unpredictability prevents guessing another client’s key.
- Reproducible IDs from natural keys: v5 with a dedicated namespace.
You can generate v4 IDs instantly with the UUID Generator, and create cryptographically random tokens with Secure Random Data when a bare UUID shape is not required.