UUID Versions Explained: v1, v4, v5 and v7 — Which Should You Use?

Reading a UUID

A UUID is written as 32 hexadecimal digits in five groups, 8-4-4-4-12:

f47ac10b-58cc-4372-a567-0e02b2c3d479
              │    │
              │    └─ variant: 8, 9, a or b = RFC 9562 layout
              └────── version: 4

The first digit of the third group is the version. The first digit of the fourth group encodes the variant; for standard UUIDs it is always 8, 9, a or b. So you can tell a v4 from a v7 at a glance. Two special values also exist: the nil UUID (all zeros) and the max UUID (all f).

The versions you will meet

UUIDv4: random, simple, everywhere

A version 4 UUID has 122 bits of randomness (the remaining 6 bits are the version and variant). Generated with a cryptographically secure random source — crypto.randomUUID() in browsers and Node.js, uuid.uuid4() in Python, UUID.randomUUID() in Java — collisions are not a practical concern.

How unlikely? By the birthday bound you would need to generate about 2.7 × 10^18 v4 UUIDs before the chance of a single duplicate reaches 50%. At a billion UUIDs per second that takes roughly 85 years. Real-world duplicates almost always come from a bad random number generator (for example, a VM image cloned with a fixed seed, or Math.random()-based code), not from bad luck.

UUIDv7: why databases prefer it

Random v4 keys are scattered evenly across the keyspace, so every insert lands on a random page of a B-tree index. On large tables that causes page splits, poor cache locality and index bloat — especially in MySQL/InnoDB, where the primary key is the clustered index.

UUIDv7 puts a Unix timestamp in milliseconds in the first 48 bits, followed by random bits. New IDs are therefore roughly increasing, inserts append to the end of the index like an auto-increment integer would, and you can sort by ID to get creation order — while keeping the "generate anywhere, no coordination" property. PostgreSQL 18 includes a built-in uuidv7() function, and libraries exist for every major language.

The trade-off: a v7 UUID reveals when it was created (to the millisecond). If IDs are exposed publicly and creation time is sensitive, use v4.

UUIDv5: the same input always gives the same ID

Version 5 hashes a namespace UUID together with a name using SHA-1. The same namespace and name always produce the same UUID, which is useful for idempotent imports or for deriving a stable ID from a URL or email address. RFC 9562 defines namespaces for DNS names, URLs, OIDs and X.500 names. v5 is not meant to be secret: anyone who knows the name can compute the ID.

Storing UUIDs efficiently

• PostgreSQL — use the native uuid type (16 bytes), not text (36+ bytes).
• MySQL 8 — store as BINARY(16) with UUID_TO_BIN(uuid, 1); the swap flag reorders v1 timestamps for better index locality. For v7 do not swap — it is already time-ordered.
• APIs and logs — use the canonical lowercase hyphenated form. Parsers should accept uppercase too; RFC 9562 says UUIDs are case-insensitive on input.

The UUID Generator can output standard, uppercase, no-hyphen and .NET brace formats for pasting into code, SQL seed scripts or test fixtures.

Quick recommendations

• New database primary keys: v7.
• Opaque public IDs, tokens' jti claims, correlation IDs: v4.
• Stable IDs derived from existing names: v5.
• Avoid v1 in new systems, and never use UUIDs as secrets — use a random password or key instead.

FAQ

What is the difference between a UUID and a GUID?

Nothing meaningful — GUID is Microsoft's name for the same 128-bit identifier. .NET often displays GUIDs in uppercase and wrapped in braces, like {F47AC10B-58CC-4372-A567-0E02B2C3D479}.

Can two UUID v4 values ever be the same?

In theory yes, in practice no: you would need around 2.7 quintillion random v4 UUIDs for a 50% chance of one duplicate, provided they come from a cryptographically secure random generator.

Is UUIDv7 a standard?

Yes. UUID versions 6, 7 and 8 were standardised in RFC 9562, published in May 2024, which obsoletes RFC 4122.