UUID v4 vs v7: which one should you use in 2026?

uuid database developer-tools

UUID v4 vs v7: which one should you use in 2026?

If you have ever generated a primary key in the last decade, you have probably reached for UUID v4. It is the default in crypto.randomUUID(), in Postgres gen_random_uuid(), and in almost every ORM. But in 2026, RFC 9562 officially replaced RFC 4122 and brought UUID v7 into the spotlight. This article is a practical comparison so you can decide which one to use in your next project.

Want to try both right now without installing anything? Use the free UUID Generator — runs entirely in your browser, no data leaves your machine.

TL;DR

  • UUID v4 is fully random. Use it when you do not care about sortability and you want maximum unpredictability.
  • UUID v7 is time-ordered. Use it when you store IDs in a database, especially as a primary key, and you care about index fragmentation, range queries, or chronological sorting.
  • For almost every new application in 2026, UUID v7 is the better default.

What changed with RFC 9562

RFC 4122 (2005) defined UUID v1 (time + MAC), v2 (DCE Security), v3 (MD5 namespace), v4 (random), and v5 (SHA-1 namespace). For 18 years, v4 was the de facto choice because v1 leaked MAC addresses and v3/v5 were niche.

RFC 9562 (May 2024) officially obsoleted RFC 4122 and added three new variants:

  • UUID v6 — reordered v1 (timestamp first, then node). Backwards-compatible conceptually but rarely adopted.
  • UUID v7 — 48-bit Unix timestamp (ms) + 12 random bits + 62 random bits. Sortable, modern.
  • UUID v8 — vendor-defined. You decide the layout.
The interesting one for application developers is v7, because it solves the single biggest complaint about v4 in databases: index fragmentation.

Structure comparison

UUID v4 layout (122 bits of randomness)

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
        ^    ^    ^
        |    |    variant (1 bit: 10xx)
        |    version (4 bits: 0100)
        random (122 bits total)

Every bit except the version and variant is cryptographically random. Two v4 UUIDs generated a millisecond apart are completely uncorrelated.

UUID v7 layout (time-ordered)

xxxxxxxxxxxx-7xxx-yxxx-xxxxxxxxxxxx
^^^^^^^^^^^^    ^    ^
Unix ms (48)    |    variant (10xx)
                version (0111)
                random_a (12 bits)
                random_b + counter (62 bits)

The first 48 bits encode the Unix timestamp in milliseconds. UUIDs generated close in time sort lexicographically close in storage. The remaining 74 bits are random, preserving global uniqueness.

Why time-ordering matters in databases

The B-tree problem with v4

Most databases (Postgres, MySQL InnoDB, SQLite) store rows in a B-tree index. When you insert a random v4 UUID as a primary key, the new row can land anywhere in the index — sometimes in a page that is already full, triggering a page split. Page splits fragment the index, write amplification goes up, and cache locality goes down.

A classic benchmark (Citus, 2018) on Postgres showed that inserting 100 million rows with a v4 primary key took roughly 2× longer than with a sequential bigint, and the final index was significantly larger. The difference gets worse as the table grows, because random inserts touch more cold pages.

Why v7 fixes this

UUID v7 inserts in roughly chronological order. New rows append to the right edge of the B-tree, which means:

  • No page splits on the hot path — new rows usually fit in the last page.
  • Better cache locality — recent inserts stay in the same few buffer pages.
  • Smaller index size — less fragmentation means less wasted space.
  • Range scans are fast — rows for "today" are physically contiguous.
For a write-heavy table (events, logs, orders), the difference can be 1.5× to 3× throughput at scale. For read-heavy tables with random access, the difference is smaller but the index-size win still holds.

Collision probability

v4

A v4 UUID has 122 bits of randomness. The probability of a collision follows the birthday paradox:

  • 2.71 × 10¹⁸ v4 UUIDs before a 50% collision chance.
  • To see a 1-in-a-billion collision probability, you need about 2.6 × 10¹⁵ UUIDs.
For any realistic application, v4 collisions do not happen.

v7

UUID v7 has 74 bits of randomness per millisecond (12 + 62). Within the same millisecond, the birthday bound is around 2.4 × 10¹¹ UUIDs — still absurdly high. Across different milliseconds, the timestamp disambiguates, so collisions are effectively impossible.

Neither v4 nor v7 will collide in practice.

Sortability and external systems

UUID v7's time-ordering has benefits beyond the database:

  • Log correlation — events sorted by v7 UUID are automatically in chronological order.
  • Object storage — S3/GCS keys that are v7 UUIDs sort lexicographically by creation time.
  • Distributed systems — a v7 UUID generated on machine A at time T sorts before a v7 UUID generated on machine B at time T+1ms, with no clock coordination.
  • Event sourcing — append-only event logs get natural ordering for free.
UUID v4 gives you none of this.

Predictability and security

A common concern with v7: "Does the timestamp leak information?"

Yes, a v7 UUID reveals the millisecond it was created. This is usually fine — created_at columns reveal the same thing. But there are cases where it matters:

  • Private URLs — if you use UUIDs as unguessable tokens in URLs (password reset, share links), v7 is a poor choice because an attacker who learns one UUID can narrow down the timestamp range of future UUIDs. Use v4 for capability tokens.
  • Anonymous IDs — if the timestamp itself is sensitive, v7 leaks that. Use v4 or hash the v7 before exposing it.
For internal primary keys, the timestamp leak is a non-issue.

Language and database support (2026)

Languages

Languagev4v7
JavaScript / browsercrypto.randomUUID() (native)uuid npm package v11+
Node.jscrypto.randomUUID()uuid package, or uuidv7 package
Pythonuuid.uuid4() (stdlib)uuid.uuid7() in 3.13+ stdlib
Gogithub.com/google/uuid v1.3+github.com/google/uuid v1.6+
Rustuuid crateuuid crate v1.10+
JavaUUID.randomUUID()com.github.f4b6a3:uuid-creator
C# / .NETGuid.NewGuid().NET 9+ Guid.CreateVersion7()

Databases

Databasev4v7
Postgresgen_random_uuid() (native)uuid_generate_v7() in pgcrypto 1.5+
MySQL 8app-side v4app-side, store as BINARY(16)
SQLiteapp-side v4app-side v7
MongoDBObjectId (similar concept)app-side v7

Decision tree

  • Is this ID used as a capability token in a URL? (password reset, share link)
    • - Yes → use v4. Unpredictability matters more than sortability.
  • Is this ID a database primary key on a write-heavy table?
    • - Yes → use v7. Index fragmentation is your enemy.
  • Do you need to sort by creation time without a separate timestamp column?
    • - Yes → use v7.
  • Are you replacing an existing v4 system and cannot migrate?
    • - Stay on v4. Mixed UUID versions in one column are fine.
  • Not sure?
    • - Use v7 for new primary keys, v4 for capability tokens.

    Try it yourself

    Open the free RuMystic UUID Generator:

    • Generate v1, v4, and v7 in one click.
    • Bulk generate up to 10,000 at once.
    • Copy as JSON array, plain text, or SQL VALUES clause.
    • No upload — your generated UUIDs stay in your browser.
    Generate away.