The Database Performance Crisis

While UUIDv4 solved the uniqueness and complexity problems, it introduced a severe performance regression in relational databases. To understand why RFC 9562 introduced v7, we must understand the internals of database indexing.

6.1 The B-Tree Index Structure

Most Relational Database Management Systems (RDBMS) like PostgreSQL, MySQL (InnoDB), and SQL Server use B-Tree (Balanced Tree) structures for their Primary Key indexes. B-Trees are optimized for locality: data that is accessed together should be stored together.

In a B-Tree, data is stored in sorted order. When a new row is inserted with a sequential key (like 1, 2, 3 or a timestamp):

1. The database finds the "rightmost" leaf page of the index.
2. It appends the new value.
3. When the page is full, it allocates a new page.
4. Memory access is predictable; the "hot" page stays in the Buffer Pool (RAM).

6.2 The Random Write Penalty

When using UUIDv4 (Random) as a Primary Key:

1. The new ID is random (e.g., starts with 2a..., then f9..., then 01...).
2. The database must insert this ID into a specific sorted position in the B-Tree.
3. This position is likely on a "cold" page (one not currently in RAM).
4. The database must fetch that page from the disk (I/O penalty).
5. If the page is full, the database performs a Page Split: it creates two new pages, moves half the data to each, and updates the parent pointers.
6. This process dirties multiple memory pages, triggering increased WAL (Write Ahead Log) activity and decreasing write throughput.