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

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.

Decision table

Migration and QA checklist

• Inventory strict version regexes and generated-client validators.
• Test mixed v4/v7 reads before changing write behavior.
• Confirm timestamp exposure is acceptable for public identifiers.
• Verify ordering under same-millisecond generation and clock rollback.
• Measure database effects with the real workload rather than assumed benchmarks.

A realistic service decision

Consider an orders service that creates identifiers in several regions and writes them into a B-tree primary-key index. UUID v4 keeps creation time out of the identifier and works with mature libraries, but inserts arrive throughout the index. UUID v7 puts recent writes near one another because the millisecond timestamp leads the value. That can improve locality, yet it is only one part of storage performance and must be measured with the real schema, write rate, cache, and database engine.

Public exposure changes the decision. A customer who sees UUID v7 values can recover an approximate creation time even when the API omits a createdAt field. That may be harmless for public events and unacceptable for private account or incident records. The correct choice therefore combines storage behavior, ecosystem compatibility, privacy, and migration cost rather than treating a newer version as universally better.

Compatibility work before migration

Search more than the ID generator. Strict regular expressions, database constraints, OpenAPI formats, generated clients, fixtures, log parsers, sorting code, and data-warehouse transforms may assume version 4. A safe migration allows existing v4 values to remain readable while new writes gradually switch to v7. Rollback should change only the writer; readers should continue accepting both formats.

Test mixed-version datasets in every boundary where an identifier is serialized. Confirm that string casing and hyphen removal do not accidentally change ordering or validation. If the database has a native UUID type, compare its byte ordering with the application's string ordering. Record the decision about timestamp disclosure so a future public API review does not rediscover it by accident.

Evidence to collect

• Insert latency and index/page behavior from a representative dataset, not a synthetic one-row benchmark.
• Read compatibility across old clients, queues, caches, exports, backups, and analytics jobs.
• Same-millisecond generation and concurrent-host behavior under the chosen v7 library.
• Authorization tests proving that neither UUID version is treated as an access secret.
• A privacy review for endpoints, logs, and screenshots where creation timing could be inferred.
• A rollback exercise that stops new v7 writes without rewriting existing identifiers.

References

• RFC 9562: UUIDs

FAQ

Related guides