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

For 20 years, UUID v4 was the default. Random 128-bit identifiers, universally supported, zero coordination needed. Then in May 2024, RFC 9562 arrived and introduced UUID v7 — a time-ordered variant that solves v4's biggest weakness: terrible database performance at scale.

The question every developer is asking now: should I switch? Short answer — yes, for database primary keys. Long answer, including when to stick with v4, is below.

The one-minute version

What's different about v7?

UUID v4 is 122 bits of pure random data. UUID v7 replaces the first 48 bits with the current time (milliseconds since Unix epoch) followed by 74 random bits. That's the whole trick.

Side by side:

Because the timestamp is at the start, v7 UUIDs sort correctly by creation time — both as binary values and as plain strings. This tiny change has outsized consequences for databases.

Why v4 hurts databases

Postgres, MySQL, and SQL Server all use B-tree indexes for primary keys. B-trees are at their happiest when inserts are sequential — new entries append to the rightmost leaf, leaving the rest of the tree untouched.

Random v4 UUIDs scatter inserts across every leaf page in the index. Each insert triggers a disk read (the page isn't in cache), a write (to update the page), and sometimes a page split (if the page was full). On large tables, this means:

• Inserts get slower as the table grows
• The index bloats with empty space from page splits
• Cache hit rate tanks — every insert touches a different page
• Range scans slow down because data is physically scattered

At 10M rows, you won't notice. At 100M+ rows, v4 primary keys can be 2-5× slower than sequential IDs on writes. v7 fixes all of this: inserts always go to the right end of the tree, same as a BIGINT auto-increment.

The case for keeping v4

v7's timestamp is a feature for databases and a liability everywhere else. Anywhere a UUID might be exposed to an attacker or user, the creation time comes with it.

Stick with v4 when:

• Session tokens or auth cookies. Timing information can be used for replay or correlation attacks.
• Password reset links, magic-link logins, one-time URLs. Timing leaks let attackers narrow their search window.
• Public-facing IDs that don't need sorting. If someone scraping your site can count resources by watching IDs appear in order, v7 is a gift to them.

In other words: any case where the answer to "is it okay if a stranger knows when this was created?" is no.

Performance numbers

Both versions generate stupid fast — this is never the bottleneck. Rough throughput on a 2024-era dev laptop:

v7 is slightly slower because it calls the clock and does a bit more bit-manipulation. In absolute terms, both can generate millions per second on any modern runtime. Generation speed is never the real question — insert speed is.

Language support

v7 support is widespread as of 2026:

• Node/TypeScript — uuid npm package version 11+
• Python — native uuid.uuid7() in 3.14+; earlier versions use the uuid6 package
• Go — google/uuid 1.6+
• Rust — uuid crate 1.1+
• Ruby — SecureRandom.uuid_v7 in 3.3+
• .NET — Guid.CreateVersion7() in .NET 9+
• Java — no stdlib yet; use uuid-creator
• Postgres — install pg_uuidv7 or define a SQL function
• MariaDB — native UUID_v7() since 10.7

Decision guide

Try it yourself

Generate either version right now in our free UUID Generator. The tool supports all nine versions (v1–v8, Nil, Max), has a built-in inspector to decode any UUID, and runs 100% in your browser.

Paste a v7 UUID into the inspector and you'll see the timestamp decoded to milliseconds — a nice way to see the format in action.