What is a UUID Version 7?
UUID Version 7 is a time-ordered identifier format introduced in RFC 9562 (published May 2024). It addresses a long-standing limitation of UUID v4 — the lack of natural ordering — by embedding a 48-bit Unix timestamp (millisecond precision) in the most significant bits, followed by random data in the remaining bits. This design gives UUID v7 two critical properties: monotonically increasing values over time and sufficient randomness to prevent collisions.
UUID v7 was created in response to widespread adoption of non-standard time-ordered UUID variants (such as ULID, KSUID, and Twitter's Snowflake IDs) that developers created to solve the database performance problems caused by UUID v4's random distribution. By standardizing a time-ordered UUID within the existing UUID framework, RFC 9562 allows developers to get the benefits of ordered identifiers while maintaining compatibility with UUID-aware tooling, databases, and APIs.
How UUID v7 is Generated
The generation algorithm for UUID v7 is designed for simplicity and performance:
- Capture the current Unix timestamp — The current time is recorded as milliseconds since the Unix epoch (January 1, 1970, 00:00:00 UTC). This provides millisecond-precision ordering.
- Fill the random payload — The remaining 74 bits (after timestamp, version, and variant) are filled with cryptographically secure random data using
crypto.getRandomValues(). - Set the version nibble — Bits 48–51 are set to
0111(decimal 7), marking this as a version 7 UUID. - Set the variant bits — Bits 64–65 are set to
10, indicating RFC 9562 compliance.
The result is a 128-bit identifier where lexicographic string sorting corresponds to chronological creation order. UUIDs generated in the same millisecond will have the same timestamp prefix but differ in their random suffix, providing a total ordering that is chronologically correct at millisecond granularity and random within each millisecond.
UUID v7 Byte Structure
| Field | Bits | Content |
|---|---|---|
| unix_ts_ms | 0–47 | 48-bit Unix timestamp in milliseconds |
| ver | 48–51 | 0111 (version 7) |
| rand_a | 52–63 | 12 random bits |
| var | 64–65 | 10 (RFC 9562 variant) |
| rand_b | 66–127 | 62 random bits |
You can identify a UUID v7 by the third group: the first character is always 7. The first 12 hex characters encode the creation timestamp, which can be decoded back to a date.
Why UUID v7 is Better for Databases
UUID v4's random distribution is the root cause of its database performance problems. When used as a primary key with a B-tree index (the default in PostgreSQL, MySQL, and SQL Server), each new UUID v4 insert lands at a random position in the index. This causes:
- Page splits — The database must split existing index pages to accommodate the random insertion point, an expensive I/O operation.
- Cache inefficiency — Random access patterns prevent the database from keeping hot pages in the buffer pool, forcing frequent disk reads.
- Write amplification — Each split modifies multiple pages, increasing the total I/O per insert.
UUID v7 solves all three problems. Because new UUIDs are always greater than previous ones, inserts always go to the end of the index — the same sequential pattern as auto-incrementing integers. Benchmarks consistently show 2–10x write throughput improvement when migrating from UUID v4 to v7 on large tables (millions of rows).
UUID v7 vs v1: What's the Difference?
Both UUID v1 and v7 embed timestamps, but they differ in critical ways:
| Aspect | Version 1 | Version 7 |
|---|---|---|
| Timestamp epoch | Gregorian (1582-10-15) | Unix (1970-01-01) |
| Timestamp precision | 100 nanoseconds | 1 millisecond |
| Byte ordering | Non-sequential (time_low first) | Sequential (MSB first) |
| String sortable | No | Yes |
| Node field | MAC address or random | Random only |
| Specification | RFC 4122 (2005) / RFC 9562 | RFC 9562 (2024) |
UUID v7 is the modern replacement for v1 in most new applications. The key advantage is that v7 strings sort chronologically without any transformation — a property that v1 lacks due to its non-sequential byte layout.
When to Use UUID v7
- Database primary keys — The sequential ordering minimizes index fragmentation and maximizes write throughput.
- Event logs and time-series data — Natural chronological ordering simplifies queries and partitioning.
- Distributed systems requiring ordered IDs — Multiple nodes can generate locally-ordered IDs without coordination.
- Replacing ULID or custom Snowflake IDs — UUID v7 provides the same ordering benefits within the standard UUID format, maintaining compatibility with UUID columns, validators, and libraries.
Frequently Asked Questions
What is a UUID Version 7?
UUID Version 7 is a time-ordered UUID format that combines a 48-bit Unix timestamp (millisecond precision) with 74 bits of random data. It was introduced in RFC 9562 as a modern alternative to UUID v1, designed for database-friendly sequential ordering while maintaining the standard UUID format.
Why is UUID v7 better for databases than v4?
UUID v7's time-ordered structure means new IDs are always greater than previous ones, resulting in sequential B-tree index inserts. UUID v4's random values cause scattered inserts that split existing index pages, degrading write performance by 2–10x on large tables. UUID v7 gives you the distribution benefits of auto-incrementing IDs with the uniqueness guarantees of UUIDs.
Is UUID v7 supported in my programming language?
UUID v7 support is growing rapidly. Python 3.14+, Java 17+ (via libraries like java-uuid-generator), Go (google/uuid), Rust (uuid crate), Ruby, and JavaScript all have UUID v7 implementations available. Most UUID libraries have added v7 support since RFC 9562 was published in May 2024.
Can I extract the timestamp from a UUID v7?
Yes. The first 48 bits (12 hex characters) of a UUID v7 contain a Unix timestamp in milliseconds. To extract it, parse the hex value and convert it with new Date(parseInt(uuid.slice(0,8) + uuid.slice(9,13), 16)). This reveals the creation time with millisecond precision.
Should I migrate from UUID v4 to v7?
Consider migrating if you use UUIDs as database primary keys and experience write performance issues from index fragmentation. The migration is straightforward since both versions produce standard 128-bit UUIDs in the same string format. Existing v4 UUIDs can coexist with new v7 UUIDs in the same column — the database treats them identically.