UUID Generation: v4 vs v7 - Which Should You Use?
UUIDs are the backbone of distributed systems, but not all UUIDs are created equal. As we move into 2025, the choice between the random v4 and the time-ordered v7 has massive implications for your database performance.
The History of UUIDs
Universally Unique Identifiers (UUIDs) were designed to allow distributed systems to generate unique identifiers without a central coordinating authority. Traditionally, Version 4 (v4) has been the most popular choice due to its simplicity and high randomness.
UUID v4: The Random Heavyweight
UUID v4 is generated using 122 bits of random data. This makes it incredibly unlikely to ever have a collision (roughly 1 in 2^122).
The Downside: Index Fragmentation
In databases like PostgreSQL, MySQL, or SQL Server, primary keys are typically stored in a B-Tree index. B-Trees are designed to work best with sequential data. Because UUID v4 is completely random, new records are inserted at random locations in the index.
This causes "locality of reference" issues. As the table grows, the database must constantly swap index pages in and out of memory (disk I/O), leading to significant performance degradation during high-concurrency writes.
UUID v7: The Modern Successor
The recently standardized UUID v7 solves the fragmentation problem by incorporating a 48-bit Unix timestamp at the beginning of the identifier.
Structure of UUID v7: [ 48 bits: timestamp ] [ 4 bits: version ] [ 12 bits: random ] [ 2 bits: variant ] [ 62 bits: random ]
Because the timestamp is at the start, UUID v7 identifiers are lexicographically sortable. This means:
- Sequential Inserts: New records are added to the end of the B-Tree index, minimizing page splits.
- Better Cache Locality: Recent records are stored near each other, making "latest" queries much faster.
- Debugging ease: You can extract the creation time directly from the ID without an extra column.
Performance Benchmarks
In various database stress tests, UUID v7 has shown up to a 50-70% improvement in insert performance compared to v4 once the index size exceeds the available RAM. For applications processing thousands of writes per second, this difference is night and day.
Conclusion: Which to Choose?
Use UUID v7 for primary keys in your database. It gives you the uniqueness of a UUID with the performance of a sequential integer.
Use UUID v4 only when you specifically want to hide the time of creation or for non-indexed identifiers where randomness is the only requirement.
Generate your own using our UUID Generator.