UUID v4 vs UUID v7: Which Identifier Should You Choose?

The Rise of Universally Unique Identifiers

In monolithic architectures, sequential auto-incrementing integer IDs (`1, 2, 3...`) were the standard database primary key. However, in distributed cloud architectures with multiple microservices and sharded databases, centralized auto-increment creates write bottlenecks and leaks business volume metrics.

UUIDs (RFC 4122 / RFC 9562) allow any client or server to generate unique 128-bit identifiers independently with zero central coordination.

UUID Version 4: Pure Randomness

UUID v4 generates 122 bits of pseudo-random entropy. While collision probability is practically zero, purely random keys create a major database issue: B-Tree Index Fragmentation.

When inserting randomly distributed UUID v4 primary keys into indexes (like PostgreSQL or MySQL InnoDB), new rows are scattered across random index memory pages, causing frequent disk I/O page splits and cache degradation.

UUID v4: c9a646d3-9c61-4cc9-bc06-a83a0824b221
(122 bits of random noise scattered across the index)

UUID Version 7: Time-Ordered Precision

RFC 9562 introduced UUID v7, combining a 48-bit millisecond Unix timestamp prefix with 74 bits of random entropy. Because v7 keys are naturally sequential over time, database inserts append smoothly to the end of B-Trees, preserving write throughput while retaining distributed uniqueness.