UUID v4 vs UUID v7: Which Should You Actually Use in 2026?

#webdev #database #backend #programming

For roughly fifteen years, "use UUID v4" has been the safe answer to any unique-identifier question in software engineering. It is random, conflict-free across distributed systems, and supported by
every standard library worth using. But in 2024 the IETF formally standardised UUID v7 in RFC 9562, and adoption has been quick — Postgres, MySQL, MongoDB, and major ORMs now all have first-class
support. If you are starting a new project or evaluating a schema change, the v4-vs-v7 decision matters more than most developers realise.

How v4 and v7 differ in structure

UUID v4 is 122 bits of pure randomness wrapped in the standard 128-bit UUID format. The structure is intentionally meaningless: every byte (except a few format bits) is generated from a
cryptographically secure random source. Two UUIDs created one millisecond apart will look completely unrelated.

randomness. The result is still globally unique with vanishingly small collision probability, but UUIDs generated at similar times sort lexicographically near each other. A v7 generated this morning
sorts before one generated this afternoon.

Why ordering matters for database performance

When you use a UUID as a primary key in a database, the engine maintains an index on it. Most relational databases use B-tree indexes, which are stored in sorted order. If incoming primary keys are
random (v4), every insert lands at a random spot in the index, fragmenting the B-tree and causing frequent page splits. On a busy table with tens of millions of rows, this materially slows inserts
and balloons disk usage.

Sorted keys — like auto-incrementing integers, or v7 UUIDs — always land at the end of the index. New pages append cleanly. Cache locality is better because recently inserted rows live near each
other on disk. Postgres benchmarks have shown insert throughput improvements of 30–50% on UUID-keyed tables when switching from v4 to v7, with comparable improvements in space efficiency.

When v4 is still the right choice

For non-database identifiers — session tokens, API keys, request IDs in distributed tracing, file uploads — v4 remains the better default. The whole point in those cases is that the ID is
unguessable and unrelated to time. A v7 leaks the creation timestamp to anyone who reads the ID, which is fine for database rows but a minor information disclosure for anything user-facing.

v4 is also the right pick if you need to obscure ordering. If your URLs use UUIDs (e.g., /orders/:uuid) and you don't want users inferring activity volume from creation patterns, v4 hides that
completely. v7 does not.

When to switch to v7

Switch to v7 when you are using UUIDs as a primary key in a relational or document database, particularly on tables that grow into the millions of rows. The performance improvement compounds as the
table grows.

Most major libraries now support v7:

Node.js — uuid package v10+
Python — uuid_utils package
Go — github.com/gofrs/uuid
Postgres 18 — gen_random_uuid_v7() built in

Migration from v4 to v7 is a one-line code change in most stacks since the column type is identical.

Other UUID versions worth knowing

v1 — timestamp + MAC address. Generally avoided because it leaks the host machine's MAC address.
v3 / v5 — deterministic, derived from a namespace+name via MD5 (v3) or SHA-1 (v5). Useful when the same input must always produce the same UUID.
v6 — a v1 variant with reordered fields for sortability. Largely superseded by v7.
v8 — custom format for application-defined schemes.

For most modern applications: v7 for database primary keys, v4 for everything else. That covers 99% of real-world use.

Originally published at qtnest.com. QTNest also has a UUID generator if you need v4 IDs
quickly.