UUID v7 Generator

UUID v7: A Modern Time-Ordered UUID

UUID v7 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.

UUID v7 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 UUID v7 particularly useful for distributed applications that want UUID compatibility together with chronological ordering and potentially better database index locality.

Who Uses UUID v7?

UUID v7 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.

UUID v7 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 UUID v7 Used?

UUID v7 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 UUID v7 specification and the implementation's chosen generation strategy.
2. Transmission - UUID v7 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 UUID v7 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. UUID v7 places the timestamp in the most significant portion of the UUID, giving the resulting values a useful chronological ordering.

Is UUID v7 Suitable for Databases?

UUID v7 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.

UUID v7 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. UUID v7 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. UUID v7 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. UUID v7 can be useful where random NEWID() values create undesirable index locality, although the appropriate clustering strategy depends on the workload.
• MySQL / InnoDB: UUID v7 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. UUID v7 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. UUID v7 can reduce the locality problems associated with random identifiers, but the actual benefit depends on the workload.

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

When Was UUID v7 Created, and Where Is It Defined?

UUID v7 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.

UUID v7 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 UUID v7 and provides a similar timestamp-plus-randomness concept, but UUID v7 is part of the standardized UUID family.

Why Was UUID v7 Created?

One of the main goals of UUID v7 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.

UUID v7 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?

UUID v7 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 UUID v7 Use All 128 Bits for Randomness?

UUID v7 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 UUID v7 the New Standard?

UUID v7 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.

UUID v7 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 UUID v7 Sortable?

Yes, UUID v7 is designed to be time-ordered.

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

However, UUID v7 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, UUID v7 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 UUID v7 Suitable for Range Queries?

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

For example, an application can use UUID v7'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.

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

Is UUID v7 Suitable for URLs?

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

For example:

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

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

However, UUID v7 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: UUID v7 contains a timestamp. A publicly exposed UUID v7 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.

UUID v7 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?

UUID v7 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 UUID v7 as security primitives.

UUID v7 vs UUID v4

The main difference is straightforward:

UUID v4 is random. UUID v7 is time-ordered.

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

UUID v7 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 UUID v7 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.
• UUID v7 - 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.

** UUID v7 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

UUID v7 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, UUID v7 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 UUID v7 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?