UUID v4 Breaks Database Performance at Scale — What UUID v7 Changed and Why It's Still Not the Default

UUID version 7 — finalised in RFC 9562 in May 2024 — introduces time-ordered UUIDs that solve the database performance problem that UUID v4's random ordering creates, while keeping the universally unique property that makes UUIDs useful in the first place

UUID v4 is the most widely used UUID version by a significant margin — it's random, simple, and universally unique. It also produces terrible database performance as a primary key in B-tree indexed databases, and this is not a minor concern — at scale, UUID v4 primary keys cause index fragmentation and write amplification that measurably degrades insert performance and storage efficiency. Understanding the tradeoffs between UUID versions leads directly to understanding how database indexes work.

Why random UUIDs break database B-tree indexes

B-tree indexes (used by PostgreSQL, MySQL/InnoDB, and most relational databases as the default index type) maintain sorted order of indexed values. When a new row is inserted, the B-tree must place it in the correct sorted position.

With sequential integers (BIGINT AUTO_INCREMENT): new inserts always go at the end of the index. The rightmost leaf page is the active insertion point — it's in memory, hot, and receives all inserts. No page splits occur for sequential insertions.

With UUID v4 (random): new inserts go to random positions in the index. The B-tree must:

1. Find the correct position (requires tree traversal — typically cached for recent positions but cold for random positions)
2. Insert the new key
3. If the target leaf page is full, perform a page split — allocating a new page, moving half the existing keys to it, and updating parent nodes

The page split problem: page splits are expensive (I/O, locking, write amplification) and random UUID inserts trigger page splits throughout the entire index rather than only at the end. At high insert rates, this produces dramatically higher write amplification and I/O compared to sequential key insertion.

Real-world impact: at sufficiently high insert rates (thousands of inserts per second), UUID v4 primary keys can reduce insert throughput by 30-50% compared to sequential keys, and increase storage overhead from fragmentation.

UUID v7: time-ordered random UUIDs

UUID v7 (RFC 9562, May 2024) structures the UUID so that the first 48 bits are a millisecond Unix timestamp:

|  48 bits  | 4 bits | 12 bits | 2 bits | 62 bits |
| timestamp |  ver   |  rand_a |  var   | rand_b  |

The time-ordering property: because the timestamp fills the most significant bits, newer UUIDs sort after older UUIDs. UUIDs generated within the same millisecond are ordered by random bits, but UUIDs from different milliseconds maintain time order.

The B-tree implication: UUID v7 inserts are approximately sequential in time — they cluster at the "recent end" of the index rather than scattered randomly throughout. The active insertion zone is small and hot in memory, similar to sequential integer behavior. Page splits are rare and concentrated at the recent end rather than distributed throughout the tree.

Benchmark comparison (approximate, varies by hardware and implementation):

• BIGINT sequential: ~100% throughput baseline
• UUID v7: ~85-90% of BIGINT sequential throughput (minor overhead from larger key size)
• UUID v4: ~50-70% of BIGINT sequential throughput at high insert rates (page split overhead)

The MAC address exposure in UUID v1

UUID v1 includes a 60-bit timestamp and the MAC address of the generating machine. This made UUID v1 uniqueness guarantees strong (tied to a specific hardware interface at a specific nanosecond) but introduced a privacy and security problem:

What MAC address exposure reveals:

• The manufacturer of the network card (from the OUI — Organizationally Unique Identifier — in the first 24 bits of the MAC address)
• A persistent identifier for the specific machine that generated the UUID — because MAC addresses don't change
• Correlatable UUIDs: two UUID v1 values from the same machine have the same last 12 hex digits, making it possible to determine they were generated by the same machine

Real-world impact: early Hotmail used UUID v1 for message identifiers, exposing user message IDs that could be correlated to identify multiple messages from the same server. Database-generated UUIDs for financial transactions could be traced to specific database servers.

The mitigation in UUID v6: UUID v6 (a reformatting of UUID v1 for better sort order) and most modern UUID v1 implementations replace the MAC address with random bytes — sacrificing the uniqueness guarantee from MAC address but eliminating the privacy problem.

UUID namespaces and version 5 (deterministic UUIDs)

UUID v5 generates a UUID deterministically from a namespace UUID and a name string, using SHA-1 hashing:

UUID_v5(namespace_uuid, "name_string") → always produces the same UUID for the same namespace and name

Use cases:

• Generating a consistent UUID for a known entity (a user's email address maps to a deterministic UUID)
• Creating content-addressable identifiers (the UUID of a document with a specific canonical URL is always the same)
• Deduplication: determining whether two records describe the same real-world entity by comparing their UUID v5 hashes

Standard namespace UUIDs defined in RFC 4122 and RFC 9562:

• 6ba7b810-9dad-11d1-80b4-00c04fd430c8 — for DNS names
• 6ba7b811-9dad-11d1-80b4-00c04fd430c8 — for URLs
• 6ba7b812-9dad-11d1-80b4-00c04fd430c8 — for OIDs (Object Identifiers)
• 6ba7b814-9dad-11d1-80b4-00c04fd430c8 — for X.500 distinguished names

Why v5 rather than v3: UUID v3 uses MD5 (deprecated cryptographic hash); UUID v5 uses SHA-1. For new implementations, v5 is preferred — though neither v3 nor v5 should be used for security-sensitive contexts (they're deterministic, not secret).

How to use the UUID Generator on sadiqbd.com

1. For new database primary key selection: generate UUID v7 samples to verify the format and understand the timestamp prefix — if your database and ORM support UUID v7, it's the recommended choice for primary keys over UUID v4 for performance reasons
2. For UUID v5 deterministic generation: generate UUID v5 with a known namespace and name to verify your implementation produces the correct result — useful for testing that two systems generating UUIDs for the same entity will produce identical values
3. For version identification: examine an existing UUID to identify its version — the character at position 14 (after the second hyphen) indicates the version (4 = random, 7 = time-ordered with timestamp prefix, 1 = time-based with MAC)

Frequently Asked Questions

If UUID v7 is better for database performance than UUID v4, why is UUID v4 still more widely used? Because UUID v4 has been the recommended default for a decade and most libraries, ORMs, and tutorials still default to it. RFC 9562 (which formally standardised UUID v7) was only published in May 2024 — before that, UUID v7 existed as a draft and was supported by a small number of early-adopter libraries. Most database ORMs (Hibernate, SQLAlchemy, Prisma, ActiveRecord) still generate UUID v4 by default because their defaults were set before UUID v7 was standardised. The ecosystem is gradually updating: PostgreSQL's gen_random_uuid() generates v4; some databases are adding v7 support as a new function. For new projects where performance at scale matters, explicitly choosing a UUID v7 implementation is worth the additional setup compared to accepting the ORM default of v4.

Is the UUID Generator free? Yes — completely free, no sign-up required.

Try the UUID Generator free at sadiqbd.com — generate UUID v4, v5, v7, and other versions instantly.