Developer Utilities

UUID v4 vs UUID v7: Which Unique Identifier Standard Should You Use?

#UUID#Databases#RFC 9562#System Design#Backend

September 17, 2026 4 min read

The Challenge of Primary Keys in Distributed Systems

In monolithic applications, database tables traditionally relied on auto-incrementing integer primary keys (1, 2, 3, ...). However, in modern distributed architectures, microservices, and multi-region database clusters, auto-incrementing sequences create severe bottlenecks:

They require centralized database locking to allocate IDs.
They leak business intelligence (e.g. an order ID of #1042 tells competitors how many orders you have processed).
They cause key collision conflicts when merging offline client records.

To solve this, developers adopted UUIDs (Universally Unique Identifiers), defined by RFC 4122.

UUID v4: The Random Workhorse

UUID v4 is generated entirely from pseudo-random or cryptographically strong random bits. Out of 128 total bits, 122 bits are purely random:

f47ac10b-58cc-4372-a567-0e02b2c3d479
                ^ (Version 4)

Advantage: Globally unique with virtually zero collision probability (the chance of two duplicate v4 UUIDs is less than one in a billion billion).
The Critical Database Flaw: B-Tree Index Fragmentation. Because UUID v4 values are completely random, inserting new rows into a database index requires inserting keys into random leaf pages of the B-Tree index. This causes continuous memory page splits, massive disk I/O write amplification, and severe database performance degradation at scale.

Enter UUID v7: The Time-Ordered Revolution (RFC 9562)

Published in 2024 as part of the updated RFC 9562 specification, UUID v7 combines the best of both worlds: time-ordered sorting and cryptographic randomness.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           unix_ts_ms                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          unix_ts_ms           |  ver  |       rand_a          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|                        rand_b                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            rand_b                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

First 48 Bits: Millisecond-precision Unix epoch timestamp.
Next 12 Bits (rand_a): Monotonic sub-millisecond counter or random entropy.
Final 62 Bits (rand_b): Cryptographically strong random bits.

Why UUID v7 Wins for Modern Databases

Monotonically Increasing: New IDs are naturally sorted chronologically. In PostgreSQL, MySQL, and SQLite, insertions append to the right edge of B-Tree indexes, eliminating page fragmentation.
Natural Time Sorting: You can sort rows by primary key to get chronological order without querying an extra created_at timestamp index.
High Concurrency Safety: Millions of IDs generated within the exact same millisecond still have guaranteed uniqueness due to 74 bits of entropy.

When to Choose Which Identifier

Requirement	Recommended ID Type
Database Primary Keys (PostgreSQL, MySQL, CockroachDB)	UUID v7 (Superior B-Tree performance)
Short-Lived Ephemeral CSRF / Nonce Tokens	UUID v4 (Pure entropy, no timestamp leak)
Public User Profiles / Obfuscated IDs	UUID v4 (Does not disclose account creation date)
Time-Series Sensor Events & Audit Logs	UUID v7 (Natural chronological order)

Generate Batch Identifiers Instantly

Whether you need classic RFC 4122 v4 identifiers for telemetry events or time-ordered UUID v7 keys for your database models, use our in-browser UUID Generator Suite. Generate batches of up to 1,000 unique identifiers with custom case and hyphen formats in milliseconds. Pair your database schema creation with our SQL Query Formatter for clean, readable code.