UUID Versions Explained: Why v4 for Keys and v7 for Database Indexes

A UUID (universally unique identifier) is a 128-bit value that can be generated anywhere — on any server, in any browser — without coordinating with a central counter. That property makes UUIDs ideal for API keys, file identifiers and distributed systems: two machines can create identifiers at the same moment without collision risk and without a round trip to the database for an auto-increment number.

The shape of the string

UUIDs are written as 32 hex digits in eight groups: 8-4-4-4-12, like 3f8a1c2e-9b4d-4e7a-8c1f-2d6e5a9b0c3d. The 13th hex digit (the first nibble of the third group) encodes the version — a 4 there means v4, a 7 means v7 — and the first digit of the fourth group encodes the variant. That is how you can identify a version at a glance, and why a well-formed UUID always shows the pattern. Behind the formatting there are only 122 meaningful bits in v4: the rest is fixed metadata.

The versions that matter

• v4 — random: 122 random bits; the version bit and variant bits are fixed, everything else is chance. Collision odds across billions of identifiers remain negligible. The safe default for public identifiers.
• v7 — time-ordered: a Unix millisecond timestamp fills the leading bits, followed by random ones. Identifiers created later sort after earlier ones, which is exactly what a database index wants.
• v1 — timestamp plus MAC address: historically common, but it leaks the hardware MAC of the generating machine and its creation time. Rarely worth that privacy cost today.
• ULID / Snowflake IDs: not UUIDs strictly speaking, but same idea — time-ordered, sortable identifiers used by high-throughput systems.

Why version choice changes index performance

Random v4 keys scatter insertions across the entire index. In InnoDB or any clustered-index engine, the table itself is ordered by the primary key, so every random insert lands on an unpredictable page: more page splits, a bloated buffer pool, and slower writes as the table grows. Time-ordered v7 keys append to the right edge of the index — the fast path — while keeping the same 128-bit uniqueness. For high-write tables, v7 versus v4 is a measurable difference, not a style preference.

One warning: unique is not secret

A UUID is an identifier, not a password. Guessing a v4 is impractical, but "unguessable" and "confidential" are different guarantees: UUIDs end up in logs, URLs, analytics and error messages, so anything that must stay secret should be a separate token built from a secure random source with enough length to survive public exposure. Never use a UUID as both the identifier and the credential of a resource.

The WhoDNS UUID generator creates v4 and v7 identifiers in bulk from a cryptographically secure random source, straight in the browser. Use it for quick fixtures, test data or one-off keys — and pick the version deliberately: random v4 for public identifiers, time-ordered v7 wherever the value becomes a primary key.

🔗 Related tool: Generate UUIDs online