Short answer: use v4 for everyday unique IDs and v7 for database primary keys. A v4 UUID is 122 bits of randomness with no order at all; a v7 UUID starts with a 48-bit Unix timestamp in milliseconds, so IDs sort by creation time. Both are standardized in RFC 9562 (2024), and you can tell them apart by the 13th hex digit — a 4 means v4, a 7 means v7.
What is inside each version
A v4 UUID fills 122 of its 128 bits with random data from a cryptographic generator. There is no timestamp, no machine identifier, nothing to read — that is the point. A v7 UUID spends its first 48 bits on the current Unix time in milliseconds, then fills the remaining 74 bits with randomness. Collisions are a non-issue for both: v4 has about 5.3 × 10³⁶ possible values, and v7 has about 1.9 × 10²² unique values per millisecond on top of the timestamp separating every millisecond.
The database problem v7 solves
PostgreSQL, MySQL, and most relational databases index primary keys with B-trees, which love sequential inserts: each new row appends to the end of the index. A v4 primary key lands at a random position on every insert, causing page splits and a fragmented index that degrades write throughput and cache locality at scale. A v7 primary key starts with a timestamp, so new IDs are monotonically increasing and inserts append cleanly — the write pattern databases want, with no central coordinator the way auto-increment needs.
Generate one in JavaScript
v4 is built into every modern browser and Node.js — no library needed. v7 is newer, so it still needs a library:
// v4 — built in, no install
crypto.randomUUID(); // "3b241101-e2bb-4d53-af18-1c9a2d80a910"
// v7 — needs the uuid package (v11+)
import { v7 as uuidv7 } from "uuid";
uuidv7(); // "018f3f5e-1c2d-7a9b-8f10-3c4d5e6f7a8b"The traps
- Leaking creation time: a v7 ID embeds a millisecond timestamp, so anyone can read roughly when the resource was created. If that reveals something sensitive, stick with v4.
- Expecting exact ordering: IDs generated in the same millisecond share a timestamp, so v7 gives time grouping, not a strict sequence. Need exact order? Keep an explicit timestamp or sequence column.
- Using UUIDs as secrets: UUIDs are unique, not unguessable-by-design. For access tokens, use a random byte string from a CSPRNG with an expiry and a way to revoke it.
- Migrating existing v4 keys: the v7 win is for new tables. Rewriting the primary keys of a live table is rarely worth the trouble.
The rule of thumb
v4 by default — ad-hoc identifiers, idempotency keys, filenames, anything where order does not matter. v7 for database primary keys and records you want roughly time-ordered without a separate timestamp column. And if you need the same input to always produce the same ID, that is v5, not v4 or v7.
Try it
Generate UUID v4s and secure passwords with the Password & UUID Generator — everything runs locally in your browser.