UUID v4 and v7: The Complete Guide for Databases and APIs

Universal Unique Identifiers show up in every stack — URLs, traces, primary keys — yet the trade-offs between versions are still routinely mixed up. Here is the practical map.

What is inside a UUID

A UUID is 128 bits printed as 8-4-4-4-12 hex digits. The third group opens with the version nibble (a 4 in v4, a 7 in v7) and the fourth group holds the variant bits. Everything else is either random or timestamp.

v4: pure randomness

v4 leaves 122 bits to random generation from the OS crypto API. Birthday math: at a billion UUIDs per second, the chance of ever seeing a duplicate stays negligible. That unpredictability also makes v4 IDs unguessable — convenient for order numbers in URLs, within limits.

v7: sortable and index-friendly

v7 prefixes a millisecond timestamp, so recent identifiers sort near each other. For databases this matters: purely random keys degrade B-tree insertion locality, while time-prefixed keys append sequentially — v7 gives smaller index churn and cheaper page splits at high write rates.

Practical rules

• Unordered storage or URLs want unguessable IDs → v4.
• High-volume tables with clustered indexes → v7 (or ULID).
• Never treat a UUID as a password or capability token by itself.

Generate batch IDs with the UUID Generator, and when you need secret material instead of identifiers, prefer the Password Generator — same CSPRNG, tuned for entropy per character.