Guide

UUID v4 vs UUID v7: Which Identifier Should You Use?

A practical comparison of random UUID v4 identifiers and time-ordered UUID v7 identifiers, with database and privacy tradeoffs.

Related tools

The short version

UUID v4 is random. UUID v7 is time-ordered. Both are 128-bit UUID formats, but they are optimized for different operational concerns.

For most application objects, test data, and public identifiers where chronological ordering is not important, UUID v4 is a simple default. When IDs are inserted into sorted indexes at high volume, UUID v7 can reduce the scattered-write behavior that random IDs often cause.

Random identifiers versus time-ordered identifiers

A UUID v4 value is mostly random data with version and variant bits set. It does not reveal when it was generated, and two values generated around the same time do not sort near each other.

A UUID v7 value starts with a Unix millisecond timestamp and then uses random bits for uniqueness. That timestamp prefix means newly generated values normally sort in creation order.

Database and index implications

Random UUID v4 values are widely supported, but they can be unfriendly to B-tree indexes in write-heavy tables because inserts land across the index instead of near the end.

UUID v7 can improve locality for append-heavy workloads because recently created IDs cluster together. That does not automatically make a database faster in every workload, but it is a real reason teams consider v7 for event tables, audit logs, and large ordered datasets.

Privacy implications

UUID v7 intentionally exposes approximate creation time. That can be useful for debugging and sorting, but it can also leak information about when a record, event, account, or transaction was created.

If creation time is sensitive, prefer UUID v4 or another identifier design that does not encode time in the public value.

When each version fits

  • Use UUID v4 when you want a broadly compatible random identifier and do not need IDs to sort by time.
  • Use UUID v7 when insertion order, log ordering, or database index locality matters and timestamp exposure is acceptable.
  • Use bulk generation only for fixtures and controlled imports, not as a replacement for ID generation inside the system that owns the data.

FAQ

Is UUID v7 a replacement for UUID v4?

Not universally. UUID v7 is useful when time ordering helps, while UUID v4 remains a strong general-purpose random identifier.

Does UUID v7 reveal exact creation time?

It includes a millisecond timestamp portion, so it can reveal approximate generation time to anyone who can parse the UUID.

Related guides