UUID v4, v5, and v7 Guide: Performance, Collisions & Database Indexing

Universally Unique Identifiers (UUIDs) are 128-bit identifiers standardized under RFC 4122 and recently updated under RFC 9562. They allow distributed distributed architectures to generate unique IDs without centralized coordination.

However, choosing the wrong UUID version can severely degrade database performance.

1. The Anatomy of a 128-Bit UUID

A UUID is rendered as 32 hexadecimal characters across five hyphenated blocks:

f47ac10b-58cc-4372-a567-0e02b2c3d479
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

• M (13th character): Represents the UUID Version (e.g. 4 for random, 7 for Unix Epoch time-sorted).
• N (17th character): Represents the Variant (e.g. 8, 9, a, or b for RFC standard).

2. UUID Versions Compared

3. The UUID v4 Database Indexing Problem

When using UUID v4 as a primary key in relational databases:

1. Every new row has an unpredictable, random hash.
2. In a B-Tree index, the new row must be inserted into an arbitrary memory page on disk.
3. Once the index exceeds available RAM, this causes massive page splits, cache thrashing, and high disk write latency.

How UUID v7 Solves This

UUID v7 stores a 48-bit millisecond Unix timestamp in the most significant bits:

┌──────────────────────────────┬──────────────┬──────────────────────────────┐
│  48-bit Unix Timestamp (ms)  │ 12-bit Rand  │       62-bit Entropy         │
│  (Sequential Ordering)       │  + Ver (7)   │       + Variant              │
└──────────────────────────────┴──────────────┴──────────────────────────────┘

Because the timestamp comes first, UUID v7 rows are inserted monotonically at the end of the B-Tree index, delivering performance nearly identical to traditional auto-incrementing integers while retaining distributed generation safety!