ksuid.net
All Comparisons

UUID v4 vs UUID v7 — Random vs Time-Sorted UUIDs Compared

UUID v4 and UUID v7 both produce 128-bit universally unique identifiers in the familiar 8-4-4-4-12 hexadecimal format, but they differ fundamentally in how those bits are allocated. UUID v4, defined by RFC 4122, fills 122 of its 128 bits with cryptographically secure random data, producing identifiers with no inherent ordering or embedded information. UUID v7, introduced in RFC 9562 (published May 2024), dedicates the first 48 bits to a Unix-epoch millisecond timestamp and fills the remaining bits with random data, creating values that are naturally sorted by creation time while maintaining the same UUID format and size.

The practical impact of this difference is most visible in database performance. When UUID v4 values are used as primary keys in B-tree indexed tables, their randomness causes inserts to land at arbitrary positions in the index, leading to frequent page splits, poor cache utilization, and write amplification. UUID v7 values, being time-ordered, are inserted near the end of the index in roughly monotonic order, resulting in sequential writes, fewer page splits, and dramatically better insert throughput. Benchmarks consistently show 2x to 10x improvements in insert-heavy workloads when switching from UUID v4 to UUID v7.

From a compatibility standpoint, UUID v7 is a drop-in replacement for UUID v4 in almost every system. Both use the same 128-bit size, the same string format, and the same database column types. The version nibble changes from 4 to 7, but all compliant UUID parsers handle this gracefully. This makes UUID v7 one of the easiest performance upgrades available for systems that already use UUID v4 as their primary key strategy.

Side-by-Side Comparison

Propertyuuiduuidv7
Bit Length128128
Output Length3636
Encodinghex (8-4-4-4-12)hex (8-4-4-4-12)
SortableNoYes
TimestampedNoYes
MonotonicNoYes
Crypto RandomYesYes
StandardRFC 4122RFC 9562

uuid Pros & Cons

Pros

  • 122 bits of pure randomness provide the highest collision resistance of any UUID version, with no information leakage about creation time or source
  • Defined by the long-established RFC 4122, making it the most widely recognized and accepted UUID version in standards-sensitive environments
  • Supported natively in every major programming language standard library and every major database engine without any additional dependencies
  • Fully random values contain no embedded timestamp, which can be a privacy advantage when creation-time leakage is a concern

Cons

  • Random values cause B-tree index fragmentation in write-heavy workloads, leading to page splits, poor cache locality, and degraded insert performance
  • No inherent ordering means chronological queries require a separate timestamp column and index, adding storage and query complexity
  • The 36-character hex format with hyphens is verbose compared to newer encoding schemes, consuming more bandwidth and storage when stored as strings

uuidv7 Pros & Cons

Pros

  • Time-ordered values produce sequential B-tree inserts, eliminating page-split fragmentation and improving write throughput by up to 10x in benchmarks
  • Embedded millisecond timestamp enables chronological range queries directly on the primary key without a separate timestamp column or index
  • Standardized in RFC 9562, giving UUID v7 the same formal standing and interoperability guarantees as UUID v4 in protocol specifications
  • Drop-in replacement for UUID v4 — same 128-bit size, same string format, same database column types — requiring minimal code changes to adopt

Cons

  • Relatively new standard (RFC 9562 published in 2024), so some older libraries, ORMs, and tools may not yet have native UUID v7 generation support
  • Embedded timestamp leaks creation-time information, which may be undesirable in privacy-sensitive contexts or public-facing identifiers
  • Slightly less randomness (approximately 74 random bits) compared to UUID v4's 122 bits, though collision probability remains negligibly small in practice

Verdict

UUID v7 is the better choice for new projects in almost every scenario, offering the same format compatibility as UUID v4 with substantially better database performance and built-in chronological ordering. UUID v4 remains perfectly valid for existing systems that are working well, and for the specific case where embedding no timestamp information is a hard requirement for privacy reasons.

Try UUID GeneratorTry UUIDV7 Generator

Frequently Asked Questions

Can I mix UUID v4 and UUID v7 in the same database column?

Yes. Both are valid 128-bit UUIDs and are stored identically in UUID-typed database columns. The version nibble differs (4 vs 7), but all compliant UUID parsers and databases handle multiple versions in the same column without issues.

How much faster is UUID v7 than UUID v4 for database inserts?

Benchmarks typically show 2x to 10x improvement in insert throughput for B-tree indexed tables, depending on the database engine, table size, and workload pattern. The benefit is most pronounced in large tables with millions of rows where index fragmentation from UUID v4 becomes significant.

Does UUID v7 make auto-incrementing integer IDs obsolete?

Not entirely. Auto-incrementing integers are still smaller (8 bytes vs 16 bytes), faster to compare, and simpler for human readability. However, UUID v7 closes the performance gap significantly and adds the benefits of decentralized generation and global uniqueness, making it a strong alternative for most distributed systems.

© 2024 Carova Labs. All rights reserved