UUIDv7 Generator

UUID version 7: A Modern Time-Ordered UUID

UUIDv7 was designed to address an important tradeoff between independently generated identifiers and database-friendly ordering.

Traditional auto-incrementing integers work well for database indexes because new values generally arrive in sequence. However, they require a central authority to allocate IDs, which can be inconvenient in distributed systems, offline applications, and architectures where multiple services or databases generate records independently.

UUID v4 removes that coordination requirement by using random data, but random ordering can provide less favorable index locality than sequential identifiers in some large, write-heavy database workloads.

UUIDv7 takes a different approach. It combines a timestamp with additional implementation-defined data, producing UUIDs that are generally ordered by creation time while retaining the ability to generate identifiers independently.

This makes UUIDv7 particularly useful for distributed applications that want UUID compatibility together with chronological ordering and potentially better database index locality.

Who Uses UUIDv7?

UUIDv7 is useful anywhere an application needs independently generated identifiers and benefits from chronological ordering.

You'll commonly encounter it in:

• Backend applications - services can generate IDs without obtaining the next value from a central database sequence.
• Distributed systems - multiple services or nodes can create identifiers independently.
• Database-backed applications - time-ordered identifiers can provide better index locality than randomly distributed UUID v4 values in appropriate workloads.
• Event-driven systems - the timestamp component provides useful chronological information directly within the identifier.
• Data pipelines and logging systems - identifiers can be ordered approximately by creation time.
• Offline applications - clients can generate identifiers before reconnecting to a central service.

UUIDv7 is not restricted to high-scale systems. It can also be useful in ordinary applications when having an identifier that carries approximate creation-time information is convenient.

How Is UUIDv7 Used?

UUIDv7 retains the standard 128-bit UUID size, so applications that already use a UUID-compatible database column generally do not need a different storage size.

A typical workflow looks like this:

1. Generation - the application obtains the current Unix timestamp in milliseconds and generates the remaining UUID fields according to the UUIDv7 specification and the implementation's chosen generation strategy.
2. Transmission - UUIDv7 values are commonly represented as standard 36-character hexadecimal strings and can be transmitted in JSON, REST APIs, GraphQL requests, and other protocols.
3. Storage - applications can store UUIDv7 using a database's native UUID type or a compact 16-byte binary representation.

The important difference from UUID v4 is the layout of the identifier. UUIDv7 places the timestamp in the most significant portion of the UUID, giving the resulting values a useful chronological ordering.

Is UUIDv7 Suitable for Databases?

UUIDv7 can be an excellent database key when an application needs globally generated identifiers and also benefits from chronological ordering.

The main advantage over UUID v4 is index locality.

Random UUID v4 values can cause inserts to target many different areas of a B-tree index. In large, write-heavy workloads, this can increase page splits, reduce locality, and increase cache and I/O activity.

UUIDv7 places the timestamp at the beginning of the identifier. Newly generated values therefore tend to be near one another in sorted order. This can provide better index locality than random UUID v4 values.

The improvement is workload-dependent. UUIDv7 does not guarantee that every insert will occur at the physical end of an index, and it should not be treated as a replacement for a database sequence.

Database performance depends on the database engine, index structure, table size, write volume, hardware, and access patterns. Benchmarking with a representative workload is still the best way to evaluate the difference.

Database-Specific Considerations

• PostgreSQL: PostgreSQL provides native uuid support. UUIDv7 can be stored using the same type used for other UUID versions, while its time ordering may provide better index locality than UUID v4.
• SQL Server: uniqueidentifier supports UUID values. UUIDv7 can be useful where random NEWID() values create undesirable index locality, although the appropriate clustering strategy depends on the workload.
• MySQL / InnoDB: UUIDv7 can provide better clustered-index locality than UUID v4. A compact binary representation can also reduce storage and index overhead compared with VARCHAR(36).
• Oracle: RAW(16) provides compact storage for UUID data. UUIDv7 can provide ordering advantages for workloads where index locality matters.
• SQLite: UUIDs can be stored as text or binary data. The performance characteristics depend on the representation, indexes, and workload.
• Managed databases: Services such as Amazon RDS, Azure SQL, and Google Cloud SQL use the behavior of their underlying database engines. UUIDv7 can reduce the locality problems associated with random identifiers, but the actual benefit depends on the workload.

UUIDv7 is therefore a useful database option, but it is not automatically the best primary-key strategy for every application.

When Was UUIDv7 Created, and Where Is It Defined?

UUIDv7 was standardized as part of the modern revision of the UUID specification.

It is defined in RFC 9562, published by the IETF in 2024. RFC 9562 updates and replaces RFC 4122 and defines UUID versions 6, 7, and 8 in addition to documenting the existing UUID formats.

UUIDv7 was designed to provide a standardized time-ordered UUID format without requiring applications to use a proprietary or unrelated identifier scheme.

This is an important distinction from formats such as ULID. ULID predates UUIDv7 and provides a similar timestamp-plus-randomness concept, but UUIDv7 is part of the standardized UUID family.

Why Was UUIDv7 Created?

One of the main goals of UUIDv7 is to combine two useful properties:

1. Independent generation - an application can create an identifier without consulting a central sequence.
2. Time ordering - identifiers can generally be sorted according to their creation time.

UUID v4 provides the first property very well, but its random values have no chronological ordering.

Sequential integers provide excellent ordering, but generating them typically requires a centralized sequence or equivalent coordination mechanism.

UUIDv7 provides a standardized middle ground. Its timestamp is placed in the most significant portion of the identifier, allowing values generated around the same time to be close together when sorted.

This can be particularly useful for database indexes, event streams, logs, and distributed applications.

Exactly How Many Bits Are Random?

UUIDv7 is 128 bits long.

Its defined layout contains:

• 48 bits for a Unix timestamp in milliseconds
• 4 bits for the UUID version, set to 0111
• 12 bits in the rand_a field
• 2 bits for the UUID variant
• 62 bits in the rand_b field

The two fields named rand_a and rand_b provide 74 bits of space that can be used for random data, but the UUID specification does not require every one of those 74 bits to be random.

Depending on the implementation, these fields can contain random data, a counter used to improve monotonicity, additional timestamp precision, or a combination of these approaches.

This is an important difference from UUID v4, where the specification defines 122 bits of random data.

Why Doesn't UUIDv7 Use All 128 Bits for Randomness?

UUIDv7 deliberately uses part of the identifier for information about the UUID format and creation time.

The 48-bit timestamp provides chronological ordering. The version and variant fields identify how the UUID should be interpreted. The remaining 74 bits provide space for randomness and other implementation-defined generation strategies.

The result is an identifier that sacrifices some random space in exchange for useful time-ordering information.

The remaining space is still extremely large. For implementations using random data in the available fields, the combination of the timestamp and random portion provides a very large identifier space suitable for normal distributed applications.

Is UUIDv7 the New Standard?

UUIDv7 is a modern standardized UUID format, but that does not mean it replaces every other UUID version.

UUID v4 remains a good choice when an application primarily needs randomly generated identifiers and does not need chronological ordering.

UUIDv7 is particularly attractive when an application wants:

• independently generated identifiers
• UUID compatibility
• chronological ordering
• better index locality than randomly distributed UUIDs
• an identifier that contains approximate creation-time information

The choice should depend on the application's requirements rather than simply using the newest UUID version.

Is UUIDv7 Sortable?

Yes, UUIDv7 is designed to be time-ordered.

The most significant portion of the UUID contains the Unix timestamp in milliseconds. As a result, UUIDv7 values can generally be sorted according to creation time when represented in their canonical form.

However, UUIDv7 should not be described as strictly monotonically increasing in the same way as a database sequence.

Multiple identifiers can be generated during the same millisecond. Multiple systems can generate identifiers concurrently, and system clocks can differ. Implementations can also use counters or additional timestamp precision to improve ordering characteristics.

Therefore, UUIDv7 provides chronological ordering, not a guarantee that every newly generated UUID will always compare greater than every UUID generated previously.

For applications that need precise event ordering, an explicit sequence, timestamp, or other ordering mechanism may still be appropriate.

Is UUIDv7 Suitable for Range Queries?

UUIDv7 can make some chronological range queries possible without requiring a separate timestamp encoded into the identifier.

For example, an application can use UUIDv7's timestamp portion to identify identifiers within an approximate time range.

However, a separate created_at column can still be useful and is often preferable when the application needs to display, filter, index, or query exact creation timestamps.

UUIDv7 should not be treated as a complete replacement for an explicit timestamp column when the timestamp itself is application data.

Is UUIDv7 Suitable for URLs?

Yes. UUIDv7 works well as a resource identifier in URLs and APIs.

For example:

https://example.com/orders/018f0d4e-7b1a-7abc-8def-123456789abc

Like UUID v4, UUIDv7 avoids exposing a simple sequential database number such as /orders/12345.

However, UUIDv7 is not a security mechanism. A difficult-to-guess identifier does not replace authentication or authorization.

There is also an important difference from UUID v4: UUIDv7 contains a timestamp. A publicly exposed UUIDv7 can therefore reveal approximate information about when the identifier was generated.

If that information is undesirable, UUID v4 or another identifier format may be more appropriate.

UUIDv7 is also relatively long at 36 characters in its canonical textual form. Applications that require very short URLs may prefer a compact identifier format such as Nano ID.

When Is UUID v4 Still Appropriate?

UUIDv7 does not make UUID v4 obsolete.

UUID v4 remains a good choice when the application needs randomly generated identifiers without embedded timestamp information.

Good use cases include:

• Random resource identifiers - when chronological information is unnecessary.
• Distributed generation - when independently generated random IDs are needed.
• Public identifiers - when exposing creation-time information is undesirable.
• Applications with modest database workloads - where UUID v4's index-locality tradeoffs are insignificant.
• Existing systems - where changing the identifier-generation strategy would provide little practical benefit.

UUID v4 can also be useful when an application specifically wants an identifier whose value does not encode creation time.

Security-sensitive credentials such as session tokens and password-reset tokens should use dedicated cryptographic token mechanisms rather than relying on UUID v4 or UUIDv7 as security primitives.

UUIDv7 vs UUID v4

The main difference is straightforward:

UUID v4 is random. UUIDv7 is time-ordered.

UUID v4 uses 122 random bits and does not contain a timestamp.

UUIDv7 contains a 48-bit Unix timestamp and additional bits that can be used for randomness, counters, or other implementation-defined generation strategies.

Choose UUID v4 when random identifiers are the primary requirement.

Choose UUIDv7 when chronological ordering and improved locality are useful.

Neither is universally better. The correct choice depends on the application architecture, database workload, storage requirements, and whether exposing approximate creation time is acceptable.

Comparison With Other Identifiers

The UUID family contains several versions designed for different requirements:

• UUID v1 - timestamp-based and includes node-related information in its traditional layout.
• UUID v3 - deterministic, name-based UUID using MD5.
• UUID v4 - randomly generated UUID with 122 random bits.
• UUID v5 - deterministic, name-based UUID using SHA-1.
• UUID v6 - a reordered, time-ordered UUID based on the UUID v1 field structure.
• UUIDv7 - a time-ordered UUID containing a Unix timestamp and additional generation data.
• ULID - a separate 128-bit identifier format containing a timestamp and 80 bits of randomness.
• Nano ID - a compact identifier with a configurable length and alphabet. It is not a UUID and does not have a fixed 128-bit structure.

Comparison Table

• UUID v1 contains timestamp information, but its canonical representation was not designed primarily for lexical sorting. UUID v6 was introduced partly to provide a more naturally sortable representation.

** UUIDv7 provides 74 bits in the rand_a and rand_b fields. Depending on the implementation, those fields may contain random data, counters, additional timestamp precision, or a combination.

Final Engineering Verdict

UUIDv7 is an excellent option for applications that need globally generated identifiers while also benefiting from chronological ordering.

Its timestamp-first layout can provide better index locality than random UUID v4 values, which makes it particularly worth evaluating for database-heavy and write-intensive workloads.

It also works well for distributed systems, APIs, event streams, logs, and applications where identifiers need to be generated independently across multiple services or machines.

However, UUIDv7 is not a universal replacement for UUID v4, sequential integers, or other identifier formats.

Use UUID v4 when randomly generated identifiers are the primary requirement and creation-time information is not needed. Consider UUIDv7 when chronological ordering and database locality are useful.

The best identifier is the one that fits the application's actual requirements. Database workload, storage format, indexing strategy, distributed-generation requirements, URL length, and information disclosure should all be considered before choosing an identifier format.

What is the UUIDv7 Text Layout?

What is the UUIDv7 Binary Layout?