UUID v4 vs v7: which one should you use?
Both look the same and both are unique enough. The difference is what is inside the first 48 bits, and that matters a lot for databases.
What is inside each one
| UUID v4 | UUID v7 | |
|---|---|---|
| First 48 bits | Random | Unix time in milliseconds |
| Random bits | 122 | 74 (some may be a counter) |
| Sorts by creation time? | No | Yes, to the millisecond |
| Reveals when it was made? | No | Yes |
| Standard | RFC 4122 (2005), now RFC 9562 | RFC 9562 (2024) |
| Example | f47ac10b-58cc-4372-a567-0e02b2c3d479 | 017f22e2-79b0-7cc3-98c4-dc0c0c07398f |
You can spot the version by eye: it is the first digit of the third group (4372, 7cc3). Paste any UUID into the UUID inspector to see its version and, for v7, the exact moment it was created. The v7 example above decodes to 22 February 2022, 19:22:22 UTC.
Why databases prefer v7
Most databases store primary keys in a B-tree index, which is kept in sorted order. Random v4 keys land all over that tree, so each insert touches a different page, pages split half-empty, and the working set no longer fits in memory once the table grows. Because v7 keys start with the time, new rows always go at the right-hand edge of the index, much like an auto-increment number. The usual result is faster inserts, smaller indexes and better caching, while you keep the advantages of UUIDs: IDs can be made anywhere, without asking the database, and they do not reveal how many rows you have.
Store them in a native 16-byte uuid column (PostgreSQL) or BINARY(16) (MySQL), not as 36-character text, which more than doubles the size of every index that uses them.
What v7 gives away
Anyone who sees a v7 UUID can read when it was created, to the millisecond. That is harmless for internal row IDs but can matter for public ones: an account ID tells people when someone signed up, an order ID shows when it was placed. If that is sensitive, use v4 for the public ID (or keep v7 internally and show a separate random ID).
Neither version is a secret. With only 74 random bits, and the timestamp guessable, v7 IDs are a little easier to guess than v4. Never use any UUID as a password-reset token or session key; use a dedicated random token of at least 128 bits for that.
Can they collide?
Not in practice. For v4 you would need about 2.7 quintillion (2.7 × 1018) IDs before the chance of a single duplicate reached one in two. For v7 the random bits only have to be unique within the same millisecond, and many generators add a counter so IDs made in the same millisecond still come out in order, which is what the generator here does.
How to make them
// JavaScript (browsers and Node 19+): v4
crypto.randomUUID()
# Python: v4, and v7 from Python 3.14
import uuid; uuid.uuid4(); uuid.uuid7()
-- PostgreSQL 13+: v4; PostgreSQL 18 adds uuidv7()
SELECT gen_random_uuid();For a quick v7 in a script or a test, the Anvil UUID endpoint returns either version over plain HTTP, no key needed.
Related
Questions
Is UUID v7 better than v4?
For database keys and anything sorted by time, usually yes: it keeps indexes compact and inserts fast. For public IDs that should not reveal their creation time, v4 is the better choice.
Can I switch an existing table from v4 to v7?
Yes. Both are ordinary 128-bit UUIDs, so they fit the same column. Old rows keep their v4 IDs and new rows get v7; only the new ones benefit from ordered inserts.
Is a GUID the same as a UUID?
Yes. GUID is Microsoft's name for the same 128-bit identifier. Some Microsoft tools write them uppercase and in {braces}, which the generator here can do too.
How can I tell which version a UUID is?
Look at the first digit of the third group: 4 means random, 7 means time-ordered, 1 and 6 are older time-based layouts. The UUID inspector on the generator page shows it for you.
Published .