Always ToolsUUID v4 vs UUID v7: Which Should You Use?
RFC 9562 (May 2024) standardized three new UUID versions — v6, v7, and v8 — alongside the classic v4. The version developers actually argue about is v4 vs v7, because it is a genuine trade-off between randomness and ordering. Here is the full picture.
UUID v4: pure randomness
UUID v4 sets 122 bits to random values and 6 bits to the version and variant markers. Every value is uniformly random: nothing about the ID reveals when or where it was created, and nobody can guess the next value.
That randomness has a cost in databases. B-tree indexes keep data physically ordered, and inserting uniformly random keys lands on random pages, causing page splits and index fragmentation. On write-heavy tables, v4 keys measurably hurt insert performance.
UUID v7: time-ordered
UUID v7 starts with a 48-bit Unix timestamp in milliseconds, followed by version bits and random bits. Values created close together sort close together, so inserts append to the same pages — the reason databases like sequential keys. You also get a useful property for free: the creation time is embedded in the ID.
The cost is privacy and security: a v7 ID leaks its creation timestamp and the random component is only 74 bits, so v7 values are easier to guess than v4. Do not use v7 where IDs must be unguessable, such as session tokens, password reset links, or anonymous identifiers.
Side-by-side
| UUID v4 | UUID v7 | |
|---|---|---|
| Structure | 122 random bits | 48-bit ms timestamp + 74 random bits |
| Ordering | None | Sorts by creation time |
| Database index behavior | Random inserts, page splits | Append-friendly inserts |
| Reveals creation time? | No | Yes (millisecond precision) |
| Guessable? | Effectively no | Harder to guess, but weaker than v4 |
| Best for | Tokens, anonymous IDs, anything unguessable | Primary keys, event logs, IDs you want sortable |
Code examples
// JavaScript (uuid npm package v11+)
import { v4 as uuidv4, v7 as uuidv7 } from 'uuid';
uuidv4(); // "3f2c9e5a-7b4d-4e2a-9c1f-8d3b6a2e4f51"
uuidv7(); // "0192f8a4-5c70-7000-8000-123456789abc"
// Java (uuid-creator)
import com.github.f4b6a3.uuid.UuidCreator;
UuidCreator.getRandomBased(); // v4
UuidCreator.getTimeOrderedEpoch(); // v7
// Python 3.14+
import uuid
uuid.uuid4() # v4
uuid.uuid7() # v7PostgreSQL 18 added a built-in uuidv7() function; on other databases generate v7 in application code and store it in a UUID column as usual.
Recommendation
- Database primary keys, event logs, or any ID you want sortable by creation time → v7.
- Session tokens, API keys, password reset links, or any ID that must not be enumerable → v4.
- Not sure, or just need unique IDs quickly → v4 is the safe default; v7 pays off only at write-heavy database scale.
FAQ
Are UUID v7 values predictable?
Partially. A UUID v7 embeds the millisecond timestamp of creation in its first 48 bits, so anyone reading it can see when it was created. If IDs must be unguessable, use UUID v4 instead.
Which databases support UUID v7?
PostgreSQL 18 added a built-in uuidv7() function. On other databases you generate UUID v7 values in your application code with libraries such as uuid (JavaScript), uuid-creator (Java), or uuid.uuid7() in Python 3.14.
Is UUID v7 sortable?
Mostly. UUID v7 starts with a millisecond timestamp, so values sort by creation time, which keeps B-tree indexes compact. Two values created in the same millisecond still contain random bits, so their relative order is not strictly chronological.