Blog · UUID guides
UUID v4 vs v7: which should you use?
Choose v4 when you want a random identifier with no embedded creation time. Consider v7 when time ordering matters, especially for new database-backed applications. An existing system does not need to migrate simply because v7 is newer.
The key differences
| Property | UUID v4 | UUID v7 |
|---|---|---|
| Size | 128 bits / 16 bytes | 128 bits / 16 bytes |
| Text format | 36 characters with hyphens | 36 characters with hyphens |
| Generation | 122 random bits plus version and variant | 48-bit Unix millisecond timestamp plus other fields |
| Ordering | No creation-time order | Timestamp first; same-millisecond order depends on generator |
| Time disclosure | No embedded timestamp | Generation timestamp is readable |
| Typical use | General-purpose random identifiers | Identifiers where time ordering is useful |
Both formats are specified in RFC 9562. If you are new to identifiers, start with what a UUID means.
How to recognize each version
In the standard hyphenated format, the first character of the third group identifies the version. Here are two illustrative values:
UUID v4 example
f47ac10b-58cc-4372-a567-0e02b2c3d479UUID v7 example
0199ac72-6f13-7c87-b22a-7024567c11d0The third groups begin with 4 and 7 respectively. Do not reuse these examples as fresh IDs. The UUID Validator can check the format and version of your own value.
Which works better as a database key?
With a B-tree index, random v4 values distribute new inserts across the index. The timestamp prefix of v7 can improve locality. This is an index behavior benefit, not a guarantee that every query or database will become faster.
Before choosing, benchmark the operations your application actually performs: inserts, ID lookups, joins and pagination. Use realistic row counts and concurrency. Keep the storage type and index definitions the same when comparing versions, so the measurement reflects the ID choice.
For an existing application, weigh a potential improvement against migration work: foreign keys, public URLs, integrations and stored references may all depend on current IDs. Replacing them without a measured reason can create more work than it saves.
Does UUID v7 give exact event order?
No. Ordering within one millisecond depends on the generator, and clocks on separate machines can disagree. An ID timestamp is not proof of when an event occurred or a transaction committed.
Store an explicit event or creation timestamp when the product needs one. For strict business ordering, such as the sequence of account transactions, use a mechanism designed for that requirement rather than relying on UUID sorting alone.
Privacy and uniqueness
A v7 UUID exposes a generation timestamp; v4 does not embed one. Neither format is a password or a substitute for authorization. Collisions remain possible: use a correct generator and enforce uniqueness where required.
For a customer-facing order URL, decide whether exposing an approximate generation time matters to your product. Separately, always verify that the requesting customer can access that order. Changing from v7 to v4 does not remove that permission check.
A practical decision checklist
Choose v4 when
- You need straightforward random IDs for fixtures, resources or general application data.
- You do not want an embedded generation timestamp.
- Your existing v4 implementation meets your performance and compatibility needs.
Consider v7 when
- You are designing a new system and have a concrete use for time-ordered IDs.
- Your database workload benefits in a realistic benchmark.
- Your libraries, validators and integrations accept version 7.
Check the whole path, including API schemas and client-side validation. A database accepting a value does not mean every downstream integration accepts it.
Try both formats
Use the UUID v4 generator for random identifiers or the UUID v7 generator for timestamp-based identifiers. Both tools run locally in your browser and support copying or downloading a batch.