UUID v4 vs v7: differences for microservices
Compare UUID v4 and UUID v7 for microservices, database indexes, event IDs, correlation IDs, and APIs, with a practical decision table.
Quick answer
Use UUID v4 when you need a simple, random, hard-to-guess identifier. Use UUID v7 when you need globally unique IDs that also sort roughly by creation time, especially for high-write databases where random UUID v4 inserts can hurt index locality.
For most modern microservices, the decision is not “UUID or no UUID.” It is where each identifier is used: public APIs, internal primary keys, event IDs, correlation IDs, idempotency keys, and database indexes all have different tradeoffs.
Why distributed systems need good IDs
Auto-increment IDs are simple inside one database. They become awkward when several services, regions, workers, queues, and databases need to create records independently.
Imagine an order flow with separate services for carts, payments, inventory, fulfillment, and notifications. If every service waits for one central database to assign IDs, the architecture becomes tightly coupled. If each service can create its own globally unique IDs, the system is easier to scale and easier to operate.
Good IDs help with:
- Creating records without central coordination.
- Merging data from different regions or shards.
- Making retries idempotent.
- Tracing events across queues and services.
- Avoiding predictable public URLs.
UUID v4
UUID v4 is random. It is widely supported, easy to generate, and a good default for public identifiers.
Strengths:
- Hard to guess.
- Good for public API IDs and URLs.
- Supported in most languages and databases.
- Does not expose creation time.
- Simple to use across services.
Tradeoffs:
- Random ordering can be inefficient for some database indexes.
- It is larger than an integer key.
- It does not naturally preserve creation order.
Use UUID v4 for public IDs, opaque resource IDs, invite tokens where a UUID is acceptable, and systems where index locality is not the bottleneck.
UUID v7
UUID v7 combines a timestamp with randomness. The result is still globally unique, but IDs are naturally sortable by time.
Strengths:
- Better index locality than UUID v4 in many write-heavy tables.
- Sorts roughly by creation time.
- Still works across independent services.
- Useful for event streams, append-heavy data, and audit trails.
Tradeoffs:
- Exposes approximate creation time.
- Requires libraries that correctly implement the newer UUID format.
- May be unnecessary for low-volume tables.
Use UUID v7 for event IDs, database primary keys in high-write tables, audit logs, append-heavy records, and distributed systems where time ordering helps debugging or querying.
v4 vs v7 comparison
| Question | UUID v4 | UUID v7 |
|---|---|---|
| Is it random? | Yes | Partly, with timestamp prefix |
| Does it sort by creation time? | No | Yes, roughly |
| Is it hard to guess? | Yes | Mostly, but creation time is visible |
| Is it database-index friendly? | Often less so | Usually better |
| Is it widely supported? | Very | Increasingly |
| Best use | Public opaque IDs | Ordered records and events |
Correlation IDs
Correlation IDs are not necessarily database IDs. They are request-tracing IDs that travel through gateways, services, queues, jobs, and logs.
UUID v4 is still a good choice for correlation IDs because it is random and widely compatible. The most important part is consistency: generate one correlation ID at the boundary, propagate it everywhere, and include it in structured logs.
request_id=6ba7b810-9dad-11d1-80b4-00c04fd430c8
service=payments
operation=authorize
status=successThe exact UUID version matters less than disciplined propagation.
Event sourcing and idempotency
Event-driven systems need stable event IDs. Those IDs help consumers detect duplicates, replay events safely, and audit what happened.
UUID v7 is a strong fit for event streams because creation order is useful during debugging and storage. UUID v4 is still valid when time ordering does not matter or when hiding timing information is more important.
For idempotency keys, think carefully. A UUID generated on every retry is not idempotent. The key must be stable for the operation being retried, often based on a client-provided request ID or a deterministic business key.
Database guidance
UUIDs are 128-bit values, so they take more storage than integer keys. They can also affect index size and cache behavior.
Practical recommendations:
- Store UUIDs in a native UUID or binary type when the database supports it.
- Avoid storing UUIDs only as long text strings in hot tables.
- Consider UUID v7 for write-heavy primary keys.
- Keep public IDs and internal storage strategy separate when needed.
- Benchmark with realistic write volume before making this a religious debate.
Some systems expose UUIDs at the API edge while keeping compact internal integer keys for hot joins. That hybrid model is reasonable when performance requirements justify it.
Implementation checklist
- Define which UUID version your organization uses by default.
- Decide when UUID v7 is preferred over UUID v4.
- Use proven libraries, not homemade UUID generators.
- Store UUIDs in efficient database types.
- Document casing, formatting, and validation rules.
- Propagate correlation IDs through logs and queues.
- Treat idempotency keys as stable operation keys, not random retry IDs.
For development and testing, a UUID generator can be useful for quick examples. In production, rely on well-maintained libraries in your application language and validate that they implement the UUID version you intend to use.
Identifier strategy is one of the architecture decisions I make explicit during full stack application development, alongside database constraints, API boundaries, idempotency, and observability.
FAQ
Is UUID v7 better than UUID v4?
Not always. UUID v7 is better when sortable, time-aware IDs help database writes or event ordering. UUID v4 remains excellent for random public identifiers.
Can UUIDs collide?
With correct generation, collisions are so unlikely that they are not usually the practical risk. Bad generators, poor entropy, and incorrect implementations are more realistic problems.
Should UUIDs be used as primary keys?
They can be. For write-heavy databases, UUID v7 or a database-native ordered UUID strategy may perform better than random UUID v4. Benchmark the storage engine you actually use.
Do UUIDs replace observability?
No. UUIDs give you identifiers. Observability comes from propagating those identifiers through logs, metrics, traces, and operational tooling.
