UUID v4 vs v7: which to use as a database key
A short rule for picking a UUID version, the index behavior behind it and the privacy trade-off most comparisons skip.
For a new database primary key, default to UUID v7, and reach for v4 only when the identifier is public and its creation time shouldn't be readable. With the UUID generator you can create v4, v7 or the nil UUID, up to 10,000 at once, in lowercase, uppercase or without hyphens, all in your browser.
What's a UUID?
A UUID is a 128-bit identifier written as 32 hexadecimal characters in groups separated by hyphens, such as 550e8400-e29b-41d4-a716-446655440000. The point is that anyone can create one without asking a central service, and a collision is astronomically unlikely. The current formats are defined in RFC 9562.
v4 vs v7 at a glance
| v4 | v7 | |
|---|---|---|
| How it's built | Almost entirely random (122 random bits) | A millisecond timestamp plus random bits |
| Ordering | None | Sorts by creation time |
| Reveals creation time | No | Yes, to the millisecond |
| Typical use | Tokens, public IDs, small tables | Primary keys on insert-heavy tables |
A v7 starts with a 48-bit Unix timestamp in milliseconds, so v7 values generated one after another sort in increasing order. In this generator, several v7 UUIDs created within the same millisecond also come out in order, since a 12-bit counter runs inside that millisecond, one of the methods the RFC describes.
Why does ordering matter to a database?
Databases keep indexes in sorted structures. With random keys (v4), each new row lands at a random spot in the index, so the engine keeps touching pages all over the tree and splitting them. With keys that grow (v7), new rows append near the end, like an auto-increment integer. You only feel the difference on heavy insert volumes: in a small table either works. And measure on your own workload, since the effect depends on the engine and the load.
What each one gives away
A v7 shows when the record was created. If the ID shows up in a public URL such as /orders/<uuid>, anyone who sees it can estimate when that order was placed. When that matters, use v4 for anything public and v7 for the internal key.
A v4 from a cryptographically secure source is unpredictable, but a UUID doesn't replace an authorization check: nobody being able to guess a URL doesn't mean anyone who has it should be allowed to open it.
Telling the version at a glance
The first character of the third group gives the version: in 550e8400-e29b-41d4-a716-446655440000 it's a 4, so it's a v4, and in a v7 it would be a 7. The first character of the fourth group is 8, 9, a or b in the RFC-defined UUIDs (the "variant"). In a v7 the first 12 hexadecimal characters are also the timestamp, so two v7 values created seconds apart share nearly the same beginning.
UUID or auto-increment integer?
- UUID: created without asking the database, which makes it easy to mint records in several services or on the client, and it doesn't expose how many records exist. It takes more space and is harder to read.
- Auto-increment integer: small, quick and easy to debug, but it requires the database to hand out the number and reveals volume in a public URL.
There's no universal answer. If you already use UUIDs, v7 gives you integer-like ordering without giving up independent generation.
Generating them, step by step
- Open the UUID generator and pick the version: v4, v7 or nil.
- Pick the format: lowercase, uppercase or no hyphens.
- Pick how many: use the 1, 10, 100 or 1000 shortcuts, or type any amount up to 10,000.
- Click generate, copy a single value or download them all as a
.txt.
The nil UUID is all zeros (00000000-0000-0000-0000-000000000000). It works as an empty value or a placeholder, not as an identifier for anything.
Practical tips
- If your database has a native
uuidtype, use it instead of storing text: it takes 16 bytes rather than 36 characters. - Choose one text format and stick with it. Mixing case or hyphenated and plain forms makes comparisons awkward.
- To turn a timestamp into a date, such as the one inside a v7 or a token, use the timestamp converter and read Unix timestamps and the 2038 problem.
Frequently asked questions
What is the difference between UUID v4 and v7?
v4 is almost entirely random and doesn't sort. v7 starts with a millisecond timestamp, so UUIDs created in sequence come out ordered, and it reveals when they were created.
Which should I use as a primary key?
On insert-heavy tables, v7, because new rows append to the end of the index. On small tables either works, and if the ID is public and shouldn't reveal its date, v4.
Is a UUID secret or safe as a token?
A v4 from a cryptographically secure source is unpredictable, but a UUID doesn't replace authorization. Don't use it as the only access protection.
What is the nil UUID?
It's the UUID made only of zeros. It serves as an empty value or placeholder, not as a real identifier.
Can two UUIDs ever repeat?
With a proper random source it's astronomically unlikely, not impossible. A uniqueness constraint in the database would catch it if it ever happened.
Generate UUID v4, v7 or nil
Up to 10,000 at a time, in lowercase, uppercase or without hyphens. Runs locally, free, no signup.
Open UUID Generator →Related tools
- UUID Generator: v4, v7 or nil, up to 10,000 at a time.
- Timestamp Converter: turn a Unix timestamp into a date.
- Hash Generator: MD5, SHA-1 and SHA-2 for text or files.
- Password Analyzer: measure a password's strength.
You might also like: what is Base64? Encoding explained in plain English, best developer tools 2026, Binary, decimal and hex: converting by hand and What's inside a JWT? Decoding vs verifying.