UUID v4 vs v7: What Changed and When to Use Each

Universally Unique Identifiers (UUIDs) are 128-bit values used as primary keys, session IDs, and correlation tokens. For most of the last decade, version 4 (random) was the go-to choice. In 2024, RFC 9562 standardized version 7 (time-ordered), and adoption is accelerating.

UUID v4: Random

v4 UUIDs are 122 bits of randomness with 6 bits of version/variant metadata. Example: 550e8400-e29b-41d4-a716-446655440000. They are simple, collision-resistant, and require no coordination between generators. The downside: they are completely random, which means database inserts scatter across B-tree index pages, causing page splits and write amplification.

UUID v7: Time-Ordered

v7 UUIDs embed a 48-bit Unix timestamp (millisecond precision) in the most significant bits, followed by random bits. Example: 01926e7a-8b3c-7d4e-a1f2-3b5c6d7e8f90. Because the timestamp comes first, sequential inserts land at the end of the B-tree — no page splits, better write performance, and natural chronological ordering.

When to Use Which

• Use v7 for database primary keys, event sourcing, log correlation, and any scenario where insertion order matters. PostgreSQL, MySQL, and most ORMs now support v7 natively or via extensions.
• Use v4 for client-side IDs, session tokens, idempotency keys, and any case where you do not want to leak timing information. The randomness in v4 means an observer cannot tell when the ID was generated.
• Avoid v1 (MAC-address-based) — it leaks hardware identity and is considered a privacy risk.

Migration Tips

If you are migrating from v4 to v7, you do not need to change existing rows. New rows get v7 IDs; old rows keep v4. Since both are 128 bits and fit in the same column type, they coexist without issues. Just update your ID generation library.

Generate UUIDs

Use the UUID Generator to create v4 or v7 UUIDs in single or batch mode. All generation happens in your browser.