UUIDs Explained: v1 vs. v4 vs. v7, and When to Use Each

UUIDs look like random noise, but the version digit (the first character after the third hyphen) tells you exactly how they were generated, what properties they have, and what they're good for. Picking the wrong version can cost you index size, leak metadata, or make your database paginate like it's stuck in tar.

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit label. That's 2¹²⁸ possible values — about 3.4 × 10³⁸ — which is large enough that if you generate a billion UUIDs per second for a hundred years, the probability of a collision is still negligible. You don't need a central authority to mint them, and you don't need to check a database to know a new one is unique.

UUIDs are written as 32 hex digits grouped in 8-4-4-4-12, separated by hyphens:

550e8400-e29b-41d4-a716-446655440000

The version is the first hex digit of the third group (4 in the example — that's a v4). The variant is the first hex digit of the fourth group (a in the example, which means RFC 4122 variant).

The version cheat sheet

There are eight versions defined in RFC 9562 (the 2024 update to RFC 4122). Here are the ones you'll actually use:

v1 — time + MAC address

The original UUID scheme. The first 60 bits are a timestamp (100-nanosecond intervals since 1582-10-15), the next 14 bits encode the clock sequence, and the last 48 bits are the MAC address of the generating machine. This means v1 UUIDs are sortable by time, but they leak the hardware they were generated on. Avoid for any user-facing identifier.

v3 — name-based (MD5)

Generated by hashing a "name" (usually a string in a namespace) with MD5. Given the same namespace and name, you get the same UUID. Useful for content-addressable identifiers where you want the same input to always produce the same output, but MD5 is considered weak for security purposes today.

v4 — random

122 bits of randomness (6 bits are reserved for version and variant). This is what most people think of when they say "UUID". v4 is what you want when you need an unguessable ID — a session token, a password-reset code, a public file ID where you don't want people enumerating your data. The trade-off: v4 UUIDs are not sortable, so they make terrible database primary keys. Inserting them into a B-tree index is a random write that fragments the index and tanks your cache hit rate.

v5 — name-based (SHA-1)

Like v3, but with SHA-1 instead of MD5. Stronger hash, same use case. Both v3 and v5 are deterministic, which is the opposite of what you usually want for a primary key.

v6 — reordered time + MAC

A 2024 reworking of v1 that puts the high bits of the timestamp first, so v6 UUIDs sort correctly as strings and as binary values. Same metadata-leakage issue as v1 (still includes the MAC address), but useful for distributed databases that want time-ordered IDs without a coordinator.

v7 — time-ordered random

The new default. v7 puts a millisecond-precision Unix timestamp in the high 48 bits, and uses the remaining 74 bits for randomness. The result: v7 UUIDs are globally unique, time-sortable, and don't leak any hardware information. This is exactly what you want from a database primary key.

v8 — custom

A "do whatever you want" version. The spec just reserves the version and variant bits; the rest is yours. Useful if you need to embed domain-specific data (a region, a shard ID, a tenant prefix) while still being a valid UUID.

Why v7 is the right default in 2026

If you are designing a new system and you need globally unique IDs, the answer is almost always v7. Here's why.

Database performance

Most primary-key indexes (B-trees, LSM-trees, whatever your database uses internally) work best when new writes append to the right edge of the index. v4 UUIDs scatter writes randomly across the index, which means more page splits, more cache misses, and more disk I/O. v7 UUIDs, being time-ordered, append to the right edge. On a write-heavy workload, this is the difference between 1,000 writes/sec and 100,000 writes/sec on the same hardware.

Concrete numbers from the Percona benchmarks: a v4 primary key on an InnoDB table can be 2–4× slower at inserts than a v7 primary key once the table is large enough that the working set doesn't fit in memory.

Sortability

v7 UUIDs sort chronologically without a secondary index. That means you can ORDER BY id and get the latest records first, or use the ID as a coarse-grained "created at" timestamp. With v4, you'd need a separate created_at column with its own index.

Unguessability

v7 still has 74 random bits — that's 1.8 × 10²² possibilities per millisecond. It's not as unguessable as v4 (which has 122 random bits), but it's not a security concern unless you're using it as a session token. For primary keys, fine. For auth tokens, stick with v4.

No metadata leakage

Unlike v1, v6, and ULID, v7 doesn't embed a MAC address or any hardware identifier. You can hand a v7 UUID to a customer, log it, embed it in a URL, or print it on a shipping label without revealing anything about the server that minted it.

UUIDs vs. auto-increment integers

Auto-increment is still the right call for some cases — small tables, internal-only data, where the row count will never exceed 2³² and you want the smallest possible index. But the moment you need to merge data from two databases, sync from a mobile client, or expose an ID to a customer without revealing your row count, UUIDs win. The flexibility of generating them anywhere — no database round-trip, no sequence — pays for the larger index size.

Common gotchas

Don't use v4 as a primary key on a write-heavy table

This is the most common mistake. If you're starting a new project in 2026, use v7. If you're stuck with v4, look at UUID reordering tricks (most databases support a function like uuid_to_bin(x, 1) in MySQL or a custom expression in Postgres).

Don't expose internal IDs in URLs without thinking

Whether v4 or v7, if the ID is enumerable, an attacker can iterate. v4 is harder to enumerate (2¹²² vs. 2⁷⁴ for v7), but neither is a substitute for proper authorization. Always check that the requesting user is allowed to see the resource.

Don't assume UUIDs are URLs

UUIDs have hyphens by convention. If you're building a slug, strip them. If you want a shorter public ID, use a separate column or a hash of the UUID.

Try it yourself

Uttir ships both a UUID v4 generator and a UUID v7 generator. Both run entirely in your browser using the Web Crypto API — the same crypto.getRandomValues your OS uses for TLS keys, so the randomness is cryptographically strong. No server roundtrip, no rate limit, no signup.

Generate a few, sort them, and notice how the v7 ones are in chronological order while the v4 ones jump around. That's the difference at a glance.