UUID v4 vs. UUID v7: The Developer Guide to Random vs. Time-Ordered Identifiers

Universally Unique Identifiers (UUIDs) are 128-bit numbers used across software engineering to uniquely identify records across distributed systems without relying on a central database authority. For decades, UUID version 4 has been the default standard. However, in 2024, the IETF ratified RFC 9562, introducing UUID version 7. Understanding the architectural differences between v4 and v7 is critical for modern database design.

The Anatomy of a 128-Bit UUID

A canonical UUID is represented as a 36-character string comprising 32 hexadecimal digits separated by four hyphens in an 8-4-4-4-12 pattern (for example: `f47ac10b-58cc-4372-a567-0e02b2c3d479`). Beneath the representation lies 16 raw bytes.

UUID v4: Pure Cryptographic Randomness

UUID version 4 utilizes 122 bits of cryptographically secure random entropy (with 6 bits reserved for version and variant flags). Because every generated ID is scattered uniformly across the 128-bit keyspace, the probability of generating a duplicate is virtually zero: with 5.3 × 10^36 possible identifiers, a system would have to generate 1 billion UUIDs per second for roughly 85 years before reaching a 50% probability of a single collision.

The Database Bottleneck: B-Tree Index Fragmentation

While UUID v4 is unbeatable for unguessable tokens, it creates severe performance degradation when used as a database primary key. Relational database engines like PostgreSQL, MySQL (InnoDB), and SQLite organize clustered primary keys using B-Tree indexes. When keys arrive in random order:

- New rows must be inserted into random memory and disk pages rather than appended to the end.

- Page splits occur frequently, doubling disk I/O and halving index density.

- Cache locality is eliminated, causing severe query cache misses on multi-gigabyte tables.

Enter UUID v7: Time-Ordered Millisecond Sequentiality

UUID v7 (RFC 9562) solves this dilemma by embedding a 48-bit Unix timestamp (milliseconds since epoch) in the first 48 bits of the identifier, followed by 74 bits of pseudorandom entropy. Because the leading bits increment monotonically with time:

- Database writes append neatly to the rightmost leaf of the B-Tree index, avoiding expensive page splits.

- Index caching efficiency increases dramatically, often delivering 2x to 5x faster insert throughput in high-concurrency systems.

- You can sort records chronologically purely by their primary key without needing a separate `created_at` index.

How to Generate UUIDs in Code

In modern JavaScript/Node.js, standard v4 UUIDs are native: `crypto.randomUUID()`. For UUID v7, lightweight libraries or web crypto byte manipulations can be used. In PostgreSQL 17+, native support and extension functions enable zero-overhead v7 generation.

Instant In-Browser UUID Generation

Need to test, mock, or generate bulk UUID v4 or v7 records for API testing or database migrations? Try Toolstack's free [UUID Generator](/en/uuid-generator). It runs entirely client-side using the Web Crypto API.