UUID v4 vs v7: When to Upgrade

UUID v4 has been the default for years — 122 random bits, no ordering, no metadata. It works, but it creates a problem at scale: random IDs fragment database indexes.

UUID v7, standardized in RFC 9562 (2024), fixes this by prepending a Unix timestamp.

Structure comparison

UUID v4:  random | random | random | random
UUID v7:  unix_ms (48-bit) | version | rand_a (12-bit) | rand_b (62-bit)

Property	v4	v7
Sortable	No	Yes (by time)
Index-friendly	No — random insertion points	Yes — append-mostly
Privacy	No pattern	Coarse timestamp reveals creation time
Collision risk	122 random bits	74 random bits (still astronomically safe)
Format	xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx	0191b8d4-7e1c-7xxx-xxxx-xxxxxxxxxxxx

Why v7 wins for databases

With v4, every insert lands at a random position in the B-tree. Pages split frequently, cache locality degrades, and write amplification increases. With v7, new rows append near the end of the index — sequential inserts, fewer page splits, better cache utilization.

Benchmark data from production systems shows 2-4x faster inserts at scale with v7 compared to v4 as the primary key.

When v4 is still fine

• Short-lived IDs — session tokens, request IDs, cache keys where you never index by time.
• Client-generated IDs that must be unguessable — v7's timestamp gives a coarse creation-time signal.
• Legacy systems — migration cost may not be worth it.

When to switch to v7

• Primary keys in PostgreSQL, MySQL, or SQLite — the index locality alone justifies it.
• Event sourcing — v7 IDs sort chronologically without a separate created_at column.
• Distributed systems — multiple nodes can generate v7 IDs without coordination, and they still sort correctly.

// v7 timestamp is the first 48 bits
function uuidv7Timestamp(uuid) {
  const hex = uuid.replace(/-/g, '').slice(0, 12)
  return parseInt(hex, 16)
}

The UUID Generator generates v1, v4, v7, and NIL UUIDs in bulk, validates existing UUIDs, and extracts embedded timestamps from v1 and v7.