Developer guides
UUID v4 vs UUID v7: Which Should You Use?
Updated 25 September 2026 · 4 min read
Both are 128-bit IDs written as 36 characters, like xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where M is the version. The difference is what goes inside.
UUID v4: random
122 of the 128 bits are random. Collisions are practically impossible, and the ID reveals nothing. But because each new ID lands in a random place, inserting millions of them into a B-tree index (a primary key in MySQL or PostgreSQL) scatters writes across the index — slower inserts and more fragmentation.
UUID v7: time-ordered
The first 48 bits are the Unix time in milliseconds; the rest are random. IDs created later sort later, so new rows go to the end of the index — like an auto-increment number — while remaining unique across servers without coordination.
Generate v4 or v7 UUIDs in bulkGenerate random v4 or time-ordered v7 UUIDs in bulk, cryptographically secure.Which to use
| Use case | Pick |
|---|---|
| Database primary keys, event logs, anything sorted by time | v7 |
| Tokens, public IDs where creation time shouldn't be visible | v4 |
| Existing systems that already use v4 | Keep v4 — both fit the same column |
Neither is a secret: don't use a UUID as a password-reset token on its own — use a proper random token and store its hash.
Frequently asked questions
Is UUID v7 an official standard?
Yes. UUID versions 6, 7 and 8 were standardised in RFC 9562 (May 2024), which replaced the original UUID RFC 4122.
Can UUID v7 leak information?
It reveals when the ID was created (to the millisecond). If creation time is sensitive, use v4.