UUID v7 is a time-ordered UUID version standardized by RFC 9562 (2024). It embeds a Unix timestamp in milliseconds in its first 48 bits, followed by random bits — so IDs generated later sort after earlier ones, unlike random v4 IDs. It's designed as the modern default for database primary keys.

Is UUID v7 better than v4?

For database primary keys, usually yes — time-ordering gives much better index locality. But v4 remains better when you need creation-time privacy or maximum compatibility with older libraries. "Better" depends on the job; the article's decision framework covers both.

In practice, no. A v4 UUID has 122 random bits — about 5.3 × 10³⁶ possibilities. You'd need to generate around 2.7 quintillion IDs for a 50% collision chance (birthday bound). You will run out of disk, budget, and patience first.

Does UUID v7 reveal the creation time?

Yes — the timestamp is right there in the first 48 bits, readable by anyone. If exposing when a record was created is a privacy or business concern (e.g. user IDs in public URLs), prefer v4.

Which UUID version should I use for database primary keys?

v7, in most cases. Time-ordered inserts keep B-tree indexes compact and fast, avoiding the page splits and fragmentation that random v4 inserts cause. v4 is the fallback when timestamp exposure or legacy library support rules out v7.

v7 UUIDs sort in creation order (by timestamp, then random bits). v4 UUIDs are random and have no meaningful sort order. Note "sortable" for v7 means chronological ordering — IDs created in the same millisecond order randomly among themselves unless the generator adds a monotonic counter.

The 2024 specification that standardized UUID versions 6, 7, and 8 (and clarified 1–5). Before it, v7 existed only as drafts with competing layouts; RFC 9562 fixed the official format, which is why library support has been converging since.

UUID v4 vs v7: Which Version Should You Use?

September 26, 2026 · Web Development

For twenty years, UUID v4 was the default unique ID: random, ubiquitous, good enough. Then UUID v7 arrived — standardized in RFC 9562 (2024) — and database engineers started migrating. This guide compares them honestly: what each version actually is, why databases prefer v7, and the cases where v4 still wins.

What a UUID is, in one paragraph

A UUID (Universally Unique Identifier) is a 128-bit label written as 32 hex digits in five groups: 123e4567-e89b-12d3-a456-426614174000. The "version" digit (the first character of the third group — here 1) records how the ID was generated. The design goal is IDs you can generate anywhere, without coordination, and still treat as globally unique.

UUID v4: random, and why it was the default

v4 fills 122 of the 128 bits with random data (6 bits are fixed: version + variant markers). Example: f47ac10b-58cc-4372-a567-0e02b2c3d479 — note the 4 starting the third group. Randomness is v4's whole strategy: with 2¹²² possibilities, collisions are a theoretical curiosity, and generation needs no clock, no coordination, no state. That's why it became the default — it works everywhere, depends on nothing.

The cost is ordering: v4 IDs are uniformly scattered, which is exactly what database indexes hate (see below).

UUID v7: time-ordered, standardized in 2024

v7 keeps the UUID format but changes the recipe: the first 48 bits are a Unix timestamp in milliseconds, then version/variant bits, then 74 random bits. Example: 0193a5f2-7c1d-7b2e-9f3a-8c4d5e6f7a8b — the leading 7 marks the version, and the timestamp prefix means IDs created later sort after earlier ones.

v7 existed as competing drafts for years; RFC 9562 (2024) fixed the official layout, and libraries have been converging on it since. One subtlety: ordering is by millisecond — IDs minted within the same millisecond order randomly unless the generator adds a monotonic counter (good implementations do).

Side-by-side comparison

	UUID v4	UUID v7
Generation	122 random bits	48-bit ms timestamp + 74 random bits
Ordering	Random — no meaningful sort	Time-ordered (chronological sort)
Privacy	Reveals nothing	Reveals creation time to anyone
DB index behavior	Scattered inserts, fragmentation	Append-mostly inserts, compact indexes
Needs a clock	No	Yes (millisecond resolution)
Standard	RFC 4122 (2005)	RFC 9562 (2024)
Library support	Universal	Widespread now, check older stacks

Generate and inspect both: our free UUID Generator creates v4 and v7 IDs in bulk and shows each ID's version, variant, and embedded timestamp.

Why databases like v7: B-tree locality in plain words

Database indexes (typically B-trees) keep entries sorted. Inserting random v4 keys means every insert lands on a random page — pages split constantly, the index fragments, and writes slow down as the table grows. Inserting time-ordered v7 keys means each new key goes after the previous one: append-mostly writes, minimal splitting, compact indexes. For write-heavy tables with UUID primary keys, this is a real, measurable performance difference — it's the entire reason v7 exists.

When to stick with v4

v7 isn't a universal upgrade. Choose v4 when:

Creation time is sensitive — v7's timestamp is public. User IDs in URLs, order numbers competitors could analyze, anything where "when was this created?" leaks business intelligence.
Legacy support matters — ancient libraries and strict validators may only know versions 1–5.
You have no meaningful ordering need — tokens, salts, and one-off identifiers gain nothing from time-ordering.
Clock trust is an issue — v7 assumes a sane system clock; v4 assumes nothing.

Inspecting a UUID: version, variant, timestamp

You can read any UUID by hand: the version is the first hex digit of the third group (4 or 7), the variant is encoded in the first digit of the fourth group (8, 9, a, or b = the standard variant). For v7, take the first 12 hex digits (48 bits), interpret as a number, and that's milliseconds since the Unix epoch — convert it like any Unix timestamp. It's a handy debugging trick when tracing "which record came first" through logs.

Frequently asked questions

What is UUID v7?: UUID v7 is a time-ordered UUID version standardized by RFC 9562 (2024). It embeds a Unix timestamp in milliseconds in its first 48 bits, followed by random bits — so IDs generated later sort after earlier ones, unlike random v4 IDs. It's designed as the modern default for database primary keys.
Is UUID v7 better than v4?: For database primary keys, usually yes — time-ordering gives much better index locality. But v4 remains better when you need creation-time privacy or maximum compatibility with older libraries. "Better" depends on the job; the article's decision framework covers both.
Can UUIDs collide?: In practice, no. A v4 UUID has 122 random bits — about 5.3 × 10³⁶ possibilities. You'd need to generate around 2.7 quintillion IDs for a 50% collision chance (birthday bound). You will run out of disk, budget, and patience first.
Does UUID v7 reveal the creation time?: Yes — the timestamp is right there in the first 48 bits, readable by anyone. If exposing when a record was created is a privacy or business concern (e.g. user IDs in public URLs), prefer v4.
Which UUID version should I use for database primary keys?: v7, in most cases. Time-ordered inserts keep B-tree indexes compact and fast, avoiding the page splits and fragmentation that random v4 inserts cause. v4 is the fallback when timestamp exposure or legacy library support rules out v7.
Are UUIDs sortable?: v7 UUIDs sort in creation order (by timestamp, then random bits). v4 UUIDs are random and have no meaningful sort order. Note "sortable" for v7 means chronological ordering — IDs created in the same millisecond order randomly among themselves unless the generator adds a monotonic counter.
What is RFC 9562?: The 2024 specification that standardized UUID versions 6, 7, and 8 (and clarified 1–5). Before it, v7 existed only as drafts with competing layouts; RFC 9562 fixed the official format, which is why library support has been converging since.