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

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.

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.

UUID v7 keeps the 128-bit format but reorganises it. The first 48 bits are a Unix timestamp in milliseconds, followed by 12 bits of version-and-sub-millisecond data, followed by 62 bits of 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.

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.

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 incrementing through them or inferring activity volume from creation patterns, v4 hides that completely. v7 does not.

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. New schemas should default to v7 for primary keys; existing schemas can switch by changing the application-level generator without touching the database column type, since the format is identical.

Most major libraries now support v7. In Node.js, the uuid package added v7 in version 10. In Python, uuid7 is widely available via the uuid_utils package. In Go, github.com/gofrs/uuid supports it. Postgres 18 has gen_random_uuid_v7() built in. Migration from v4 to v7 is a one-line code change in most stacks.

UUID v1 (timestamp + MAC address) is generally avoided because it leaks the host machine's MAC address. UUID v3 and v5 are deterministic, derived from a namespace and a name via MD5 (v3) or SHA-1 (v5) — useful when you need the same input to always produce the same UUID. UUID v6 is a v1 variant with reordered fields for sortability, largely superseded by v7. UUID v8 is a custom format reserved for application-defined schemes — useful only when you have specific structural requirements.

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

QTNest's UUID Generator produces v4 UUIDs, suitable for any non-database ID use case. If you need v7 for primary keys, generate them in your application code at insert time using your language's standard library — that's the recommended pattern anyway, since UUID generation should happen as close as possible to the system that owns the data.