UUID v4 vs UUID v7 – Which Version to Use for Database Keys

UUID v4 and UUID v7 are not interchangeable. They solve different problems. UUID v4 is 122 bits of pure randomness — no embedded information, no ordering, no correlation between IDs. UUID v7 encodes a millisecond-precision timestamp in the first 48 bits, making IDs sort chronologically and insert sequentially into B-tree indexes. Using v4 as a high-volume database primary key fragments your index; using v7 where you need opacity leaks timing information. A UUID generator produces either version — knowing which to choose determines your database performance and your privacy posture.

The version choice matters at scale. A table with ten thousand rows shows no measurable difference between v4 and v7 as a primary key. At ten million rows, the index fragmentation from random v4 inserts causes measurable write slowdowns and larger-than-necessary indexes. At a hundred million rows, the difference is significant enough that engineering teams have migrated primary keys from v4 to v7 specifically to recover insert performance.

# UUID v4 — purely random, no embedded information:
f47ac10b-58cc-4372-a567-0e02b2c3d479
3d721b2e-9c04-4f8a-b835-12a47c9e6d01
a1e3908c-2b55-47dc-8f91-c67d4e823b44
# ↑ No relationship between IDs — inserts scatter across the index

# UUID v7 — timestamp prefix, then random:
018d4e7c-a234-7f12-9abc-0a1b2c3d4e5f  ← generated at T+0ms
018d4e7c-b891-7012-8def-1b2c3d4e5f60  ← generated at T+0ms (same millisecond)
018d4e7d-1234-7abc-9012-2c3d4e5f6071  ← generated at T+1ms
# ↑ First 12 hex chars encode the timestamp — IDs sort chronologically
#   New rows always insert at the end of the index — no fragmentation

What UUID v7 Changed

UUID v7 (RFC 9562, published 2024) was designed specifically to address the database performance problem caused by random UUIDs as primary keys. The format encodes a Unix timestamp in millisecond precision in the first 48 bits of the 128-bit value, followed by version and variant bits, then random data to ensure uniqueness within the same millisecond.

The result is a UUID that is still globally unique — the random suffix prevents collisions even when millions of UUIDs are generated per second — but sorts in chronological order. When used as a primary key, each new row inserts at the end of the B-tree index rather than at a random position. This is the same property that makes auto-increment integers efficient for database inserts, without the coordination requirement of a central sequence generator.

UUID v7 replaces the earlier workarounds for this problem: ULID, COMB UUIDs, and timestamp-prefixed v4 UUIDs. If you are starting a new project, v7 is the current standard for time-ordered IDs. See our guide on UUID generation online for a complete comparison of all UUID versions.

Database Index Performance

B-tree indexes — the default index type in PostgreSQL, MySQL, and most relational databases — are efficient when data inserts in order. Each new row goes at the end of the index leaf; no existing pages need to be split or reorganized.

Random UUIDs (v4) break this property. Because the 122 random bits are uniformly distributed, each new UUID is as likely to fall at any position in the index as any other. At small table sizes this is unnoticeable. As the index grows:

Table size        v4 insert cost      v7 insert cost
──────────────────────────────────────────────────────
< 1M rows         negligible diff     negligible diff
10M rows          ~15% slower         near auto-increment
100M rows         significant         near auto-increment
1B rows           major bottleneck    near auto-increment

The specific numbers depend on hardware, database version, and workload, but the direction is consistent and well-documented. PostgreSQL's native uuid type and MySQL's BINARY(16) storage both benefit from v7's sequential inserts in the same way.

When to Use UUID v4

UUID v4 is still the right choice when the embedded timestamp in v7 is a problem rather than a feature.

• Session tokens and API keys. A token whose ID leaks when it was created is a minor privacy concern in a support ticket or log file. Use v4 for identifiers that are directly user-visible or that appear in logs accessible to support teams.
• Idempotency keys. Idempotency keys in payment APIs and job queues are opaque tokens. There is no benefit to them being sortable, and making them random reduces the chance that a generated key could be predicted or influenced.
• Short-lived identifiers. For IDs that expire in minutes — CSRF tokens, one-time links, session nonces — index performance does not matter and the timestamp in v7 would leak the issuance time.
• Tables where insert volume is low. Under a million rows, the performance difference is immeasurable. Use whichever version is simpler to implement with your existing tooling.

When to Use UUID v7

UUID v7 is the better choice whenever the identifier needs to work well as a database primary key or in any context where chronological sorting is useful.

• Database primary keys at scale. Any table that will grow beyond a few million rows benefits from v7's sequential insert pattern. PostgreSQL, MySQL, SQLite, and most other databases perform significantly better with sequential primary keys.
• Event sourcing and audit logs. Event streams benefit from IDs that sort chronologically — you can scan recent events by ID range without a separate timestamp column for ordering.
• Cursor-based pagination. APIs that paginate using ID-based cursors (?after=018d4e7c-...) work correctly only if IDs sort in creation order. v7's timestamp prefix makes this reliable.
• Distributed tracing IDs. Trace and span IDs that encode a timestamp allow log aggregators to sort and correlate spans by creation time even when clock synchronization is imperfect.

Frequently Asked Questions

Conclusion

The choice between UUID v4 and v7 comes down to whether the embedded timestamp is a feature or a liability for your use case. For database primary keys at scale, v7's time-ordered format pays meaningful dividends in insert performance and index size. For tokens, session IDs, and identifiers where timing opacity matters, v4's pure randomness is the better default. Both are globally unique; the difference is structure and what that structure implies.

If you need to generate v4 or v7 UUIDs instantly, the DevToolBox UUID Generator produces both. DevToolBox tools run entirely in your browser — no signup, no install, nothing sent to a server.