UUID v4 vs v7: which should you use in 2026?

# The short answer

Use v7 for database primary keys. Use v4 for everything else.

That's it. The rest of this post is why.

# What each version is

UUID v4 is 122 random bits plus 6 fixed version/variant bits. Indistinguishable from noise.

f47ac10b-58cc-4372-a567-0e02b2c3d479

UUID v7 starts with a 48-bit Unix timestamp (milliseconds), then 74 random bits. The RFC (9562) was ratified in 2024, so tooling is solid.

018f3c9a-1234-7abc-8def-0123456789ab
└───── timestamp ──────┘└──── random ────┘

Both are 128 bits. Both render as the same 36-character string. The only difference is the high bits.

# Why v7 exists

v4 is random, which means unordered on insert. Every new row lands in a random spot in the B-tree index. Databases hate that. You get:

• Index fragmentation (every insert = new tree rewrite)
• Poor cache locality (recently-inserted rows are scattered)
• Slower range scans

v7 sorts chronologically by design. New rows land at the end of the index. B-trees love this.

<div class="callout callout-tip" role="note"><div class="callout-title">Tip</div><div class="callout-body"><p>If your primary key is a UUID v4 and your table has more than a million rows, switching to v7 on new inserts will cut your index write-amplification by 10× without any schema change.</p></div></div>

# When to use v7

• Database primary keys — especially if ordered access is common
• Event logs — time is already the natural order
• Distributed systems with loose clocks — v7's time prefix is approximate; a 100ms clock drift doesn't break anything

# When to use v4

• API tokens and session IDs — you want unpredictability, not orderability
• File names — no sorting benefit from time
• Idempotency keys — randomness matters; time doesn't
• Anything user-facing where leaking creation time is bad

# A subtle v7 gotcha

v7 UUIDs leak creation time. If your API returns v7 IDs, a stranger can tell when each record was created by decoding the first 48 bits.

For most apps this is fine (or even useful). For security tokens and private resources, stick with v4.

# How to generate

Our UUID generator produces v4 by default and v7 on a toggle. Copy one or bulk-generate up to 1000 at once.

In code:

// v4 in any modern browser or Node
crypto.randomUUID()
// v7 — use a library (uuid@9+, uuidv7)
import { v7 } from "uuid";
v7();

# Databases that have native UUID types

• PostgreSQL — uuid column type. v7 sorts naturally as a B-tree index.
• MySQL 8+ — BINARY(16) is the idiomatic choice; use UUID_TO_BIN() to insert.
• SQLite — TEXT or BLOB; both work; BLOB is smaller.
• DynamoDB — store as String; partition keys can be UUIDs.

# Related tools

• UUID Generator
• Timestamp Converter — decode the timestamp in a v7