UUID v4 vs v7: Database Performance, Indexing, and Modern Applications

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit label used to uniquely identify information in distributed systems without central coordination. UUIDs are typically rendered as 36-character strings in the form xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where the M nibble encodes the version and N encodes the variant. Originally formalized in RFC 4122, the UUID format is now governed by RFC 9562, which adds ordered variants.

UUIDs are the de-facto primary key choice for distributed applications, event-sourced systems, and any service that must generate identifiers offline or across nodes. Their 128-bit width makes accidental collision practically impossible, but as we will see, not all UUID versions behave the same way inside a database index.

How UUID v4 Works

UUID version 4, defined in RFC 4122, uses cryptographically secure random numbers for all 122 bits that are not fixed by the version and variant fields. Each generated UUID v4 is statistically independent of every other, which guarantees uniqueness but produces values that are uniformly distributed across the entire 128-bit space.

This randomness is excellent for uniqueness, but it is precisely what makes UUID v4 expensive for database engines. Because each new value can land anywhere in the sorted index, the database cannot predict where the next insert will go, defeating every optimization that relies on sequential access.

How UUID v7 Works (RFC 9562)

UUID v7 introduces timestamp ordering by embedding a 48-bit Unix epoch timestamp (in milliseconds) in the most significant bits, followed by a 4-bit version and 74 bits of randomness. Because the timestamp occupies the high bits, two UUIDs generated in chronological order will also sort in chronological order at the byte level. Defined in RFC 9562, UUID v7 is explicitly designed to fix the database performance problems of UUID v4 while remaining wire-format compatible — it is still a 128-bit UUID stored in the same column type.

RFC 9562 defines UUID version 7 as a time-ordered identifier whose value is monotonically increasing within a single node, making it ideal for use as a database primary key. The 74 random bits guarantee that even millions of UUIDs generated within the same millisecond remain unique, while the leading timestamp ensures that the index sees a steady, append-mostly stream of new keys instead of random scatter.

Database Indexing Performance Analysis

Database performance benchmarks show that switching from UUID v4 to UUID v7 can improve insert throughput by 2–4× on large tables, because ordered inserts keep the active index pages hot and avoid the random I/O pattern that thrashes the buffer pool. When UUID v4 values are inserted, the B-tree index must constantly seek to a random leaf page for each row. Under high concurrency this leads to cache misses, lock contention, and frequent page splits that fragment the index.

With UUID v7, successive inserts almost always target the rightmost leaf page of the index, which stays resident in memory. The result is sequential I/O, smaller write amplification, and dramatically lower fragmentation over time. In practice, tables that grow past tens of millions of rows show the largest gains — exactly the regime where UUID v4 begins to degrade non-linearly.

B-tree Locality Explanation

B-tree index locality significantly impacts write throughput and storage efficiency, because a B-tree maintains its invariants by splitting leaf pages only when they fill — and random inserts fill pages uniformly instead of sequentially. With UUID v4, every insert is a random probe: the engine traverses from the root to a leaf page chosen uniformly at random, writes to it, and likely causes a split that cascades up the tree. Over time the index becomes a patchwork of half-full pages.

UUID v7 changes this picture entirely. Because new values are larger than (nearly) all existing values, they concentrate on the rightmost leaf page. When that page fills, it splits once, the new rightmost page becomes the active append target, and the rest of the index is never touched. This append-mostly behavior keeps page fill factors high, reduces the index size on disk, and lets the database prefetch the next sequential page — something impossible with random UUID v4 inserts.

Migration Considerations

Migrating an existing system from UUID v4 to UUID v7 does not require rewriting stored values. Because both versions share the same 128-bit layout and the same column type (e.g. UUID in PostgreSQL, BINARY(16) in MySQL), the simplest migration is:

• ✓Switch the default on the primary key to UUID v7 for all new rows.
• ✓Leave existing v4 values untouched — they remain valid and continue to sort correctly within their own range.
• ✓Rebuild the index during a maintenance window to reclaim space lost to v4 fragmentation, then let v7 keep it compact.
• ✓Audit external references — any system parsing the version nibble will now see both 4 and 7, which is by design.

Avoid the temptation to rewrite old v4 values in place: that would break any external system that stored the original identifier and provides no real benefit, since v4 values continue to function correctly alongside v7.

Comparison Table: UUID v4 vs v7

Frequently Asked Questions

Related Tools