Certificates & Site Ops · Field note
UUID v1 vs v4 vs v7: picking an identifier you can live with later
A practical UUID guide that compares privacy, sortability, and operational behavior before your identifier choice gets baked into logs, databases, and APIs.
Before you start
Inspect the current certificate, key, token, or endpoint output before changing deployment config; stale artifacts make fixes misleading.
UUID choice looks small until the identifiers start showing up in database indexes, logs, URLs, and analytics pipelines. Then the version becomes an architectural decision, not just a helper-function default.
The useful comparison is not historical trivia. It is what each version means for privacy, randomness, sort order, and operational behavior.
In brief
What it is: UUID versions encode different generation strategies: v1 is time-and-node oriented, v4 is random, and v7 is time-ordered with modern sortability goals.
Why it matters: The choice affects observability, database locality, debugging, and how much timestamp information the ID leaks.
Watch for: Picking one solely because it is familiar can create avoidable index or privacy tradeoffs later.
v1, v4, and v7 solve different operational problems
UUID v1 carries time-oriented information and historically included node-related data, which makes it useful for ordering but awkward from a privacy and exposure perspective. UUID v4 is random and simple, which keeps it neutral and widely supported but not naturally sortable. UUID v7 was standardized to preserve broad UUID compatibility while making time ordering a first-class feature.
That means the real question is what behavior you want after generation, not just during generation.
Sortability vs exposure is the main tradeoff
Time-sortable IDs are valuable for logs, storage locality, and operational readability. The tradeoff is that a sortable identifier often reveals more about ordering and timing than a purely random one. That is not automatically bad. It just means you should choose it deliberately and understand the downstream effect.
- Choose v4 when you want a simple random default with broad support.
- Choose v7 when natural time ordering is useful and ecosystem support is acceptable.
- Treat v1 with caution in new designs unless you have a specific reason to inherit it.
Pick for the system you are building next
If IDs are mostly opaque references crossing many systems, v4 is still a reasonable default. If write ordering, timeline inspection, or index locality matter, v7 deserves serious attention. The cost of changing later is usually higher than spending five minutes on the decision now.
See it in a small example
Notice: This is an operations decision as much as an API design decision.
Opaque random default -> UUID v4
Sortable modern default -> UUID v7
Legacy time-oriented inheritance -> UUID v1 with caution
What to verify
- Decide whether natural ordering is a real requirement.
- Treat version choice as part of system design, not just helper code.
- Consider what the identifier reveals in logs and shared URLs.
Common questions
Is v7 always better than v4?
No. It is better when sortability matters enough to justify it.
Should I start new work on v1?
Usually no, unless compatibility with an existing ecosystem is the hard requirement.