UUID v7 vs UUID v4: Why Modern Databases Are Abandoning Random UUIDs

1. The Evolution from RFC 4122 to RFC 9562

For almost two decades, RFC 4122 (published in 2005) was the defining standard for UUIDs. It specified versions 1 through 5, with Version 4 (randomly generated) quickly becoming the universal choice for microservices and web APIs.

However, RFC 4122 had a major architectural blind spot: databases. Because UUID v4 values are generated with 122 bits of pseudo-random entropy, they have zero chronological locality. When used as database primary keys, newly generated IDs arrive in completely scattered alphabetical order.

To solve this problem across modern high-throughput architectures, the IETF published RFC 9562 in May 2024. This standard officially defines UUID Version 6, Version 7, and Version 8. Among these, UUID Version 7 is the recommended successor for modern application and database design.

2. The B-Tree Problem: How UUID v4 Causes Write Amplification

Relational databases like PostgreSQL, MySQL (InnoDB), CockroachDB, and SQLite organize primary key indexes using B-Tree data structures. B-Trees are optimized for clustered, sequential reads and writes.

When inserting an auto-incrementing integer (`BIGSERIAL`), the engine simply appends the new row to the rightmost leaf node of the B-Tree. The node stays in memory cache (PostgreSQL Shared Buffers or MySQL Buffer Pool), making inserts blisteringly fast.

When inserting UUID v4, every incoming primary key lands at a totally random position in the B-Tree. If the index exceeds available RAM, the database must execute a random disk read to fetch the relevant B-Tree node, insert the row, split the memory page if it is full (page split), and write dirty pages back to disk and the Write-Ahead Log (WAL).

Under sustained load, this random write amplification can degrade database insert throughput by 70% or more as table size grows beyond memory cache limits.

3. Anatomy of UUID v7: The 48-Bit Timestamp + 74-Bit Entropy Formula

UUID Version 7 solves index fragmentation while remaining 100% compliant with standard 128-bit UUID database columns (`uuid` data type):

1. unix_ts_ms (48 bits): The first 48 bits encode the Unix epoch timestamp in milliseconds (big-endian). Because higher-order bits increase over time, UUID v7 values are naturally monotonic and sort chronologically.

2. ver (4 bits): Set to `0111` (Version 7) in the high 4 bits of octet 6.

3. rand_a (12 bits): Contains sub-millisecond precision or additional pseudorandom entropy.

4. var (2 bits): Set to `10` (RFC 4122 / RFC 9562 Leach-Salz variant) in octet 8.

5. rand_b (62 bits): Cryptographically secure random entropy.

With 74 bits of total randomness alongside a 48-bit timestamp, the probability of two UUID v7 identifiers colliding within the same millisecond is virtually zero.

4. UUID v7 vs ULID: Why UUID v7 Wins for Enterprise Engineering

Before RFC 9562 was ratified, developers frequently reached for ULID (Universally Unique Lexicographically Sortable Identifier) as an alternative to UUID v4.

While ULID pioneered time-ordered identifiers, it lacks native database support. Most databases have no native `ulid` data type, forcing teams to store ULIDs as 26-character `VARCHAR(26)` strings (which consume 26 bytes instead of 16 bytes) or write custom binary serialization adapters in their ORMs.

UUID v7 provides the exact same time-ordered benefits of ULID while utilizing the official, native 16-byte `UUID` data type supported by PostgreSQL, MySQL 8+, SQLite, and CockroachDB without any custom schema hacks.

5. Code Cheat Sheet: Generating UUID v7 Across Languages

Here is how modern programming environments generate UUID v7 identifiers:

// Node.js (v22+ natively, or via 'uuid' package)
import { v7 as uuidv7 } from 'uuid';
const id = uuidv7(); // e.g. "018e6e58-6a3f-7b24-9b63-9562a1c0de94"

# Python (Python 3.14+ or 'uuid6' / 'uuid-utils' package)
import uuid6
id = str(uuid6.uuid7())

// Go (Golang) via google/uuid v1.6.0+
package main
import (
    "fmt"
    "github.com/google/uuid"
)
func main() {
    id, _ := uuid.NewV7()
    fmt.Println(id.String())
}

-- PostgreSQL 17 (Native pg_crypto / uuid-ossp or uuidv7 function)
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
-- Or in Postgres 17+:
SELECT uuid_generate_v7();