UUID v7 is the newest member of the UUID family, standardized in RFC 9562 in May 2024. It solves the biggest practical problem with UUID v4: unpredictable insertion order in databases.

The problem with UUID v4

UUID v4 is 122 bits of pure randomness. It is the de-facto standard for most applications, but it has one major drawback:

When you insert millions of v4 UUIDs into a database, they are scattered randomly across the B-tree index. Every insert is essentially a random I/O operation. On a hot table, this destroys performance.

Compare this to auto-increment IDs, which always append to the end of the index. Inserts are sequential, writes are fast, and the index stays compact.

Enter UUID v7

UUID v7 packs a 48-bit Unix timestamp in milliseconds into the most significant bits, followed by random bits and the version/variant markers:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           unix_ts_ms                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          unix_ts_ms           |  ver  |       rand_a          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|                        rand_b                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            rand_b                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The result: a UUID that is lexicographically sortable by creation time, while still containing 74 bits of randomness.

Why v7 beats v4 for databases

  • Sorted indexes — v7 UUIDs sort by time, so B-tree inserts are append-only.
  • Compact storage — v7 maintains the same 16-byte / 128-bit storage as v4.
  • No coordination — like all UUIDs, you can generate them anywhere without a central server.
  • Privacy — unlike v1, v7 does not embed a MAC address.
  • Embeddable timestamp — you can extract the creation time from a v7 UUID without a separate column.

When to use v4 vs v7

Use v4 when:

  • You want maximum unpredictability (security tokens, one-time IDs).
  • You do not care about insertion order.
  • You are generating IDs client-side at high rates.

Use v7 when:

  • You are inserting into a database with a UUID primary key.
  • You want time-ordered events (audit logs, message queues).
  • You want to extract the creation time from the ID itself.

Browser support

As of 2026, no browser ships crypto.randomUUID() for v7. The function always returns v4. For v7, you need a small library or a few lines of custom code using crypto.getRandomValues() and Date.now(). See the MDN Crypto documentation for current browser support.

Try generating v7 UUIDs with our UUID Generator.

Frequently Asked Questions

Q: What is UUID v7 and why does it exist?

UUID v7 is a time-sortable UUID standardized in RFC 9562 (May 2024). It exists to fix the database indexing problem of UUID v4 by embedding a 48-bit Unix timestamp in milliseconds at the start of the ID.

Q: Is UUID v7 better than v4 for databases?

Yes. v7 UUIDs are time-ordered, so B-tree inserts are append-only rather than random. Benchmarks show up to 7x fewer page splits on PostgreSQL and MySQL. Learn more from the official RFC 9562.

Q: Should I migrate existing v4 columns to v7?

No. Leave v4 where it lives. Use v7 for new tables and let the system age into it naturally. See our UUID v4 vs v7 comparison for detailed migration advice.