UUID version 7 Generator Tool

UUIDv7: The Modern Standard for Distributed IDs

For years, backend engineers have been caught in a frustrating trade-off. You either used auto-incrementing integers—which are great for database performance but a nightmare for distributed systems and security—or you used UUIDv4, which solved the distribution problem but absolutely destroyed your database index performance.

UUIDv7 is the industry's answer to this dilemma. It is essentially the "goldilocks" of identifiers: it provides the global uniqueness of a UUID with the sequential nature of an integer. This guide breaks down everything you need to know about UUIDv7 from a practical, engineering perspective.

Who uses it?

UUIDv7 is becoming the default choice for anyone managing high-scale data persistence. You'll primarily see it adopted by:

• Backend Developers: Specifically those building microservices where IDs must be generated on the application side to avoid the bottleneck of a central database sequence.
• Database Administrators (DBAs): DBAs love UUIDv7 because it solves the "page split" problem in B-Tree indexes, significantly reducing disk I/O and increasing write throughput.
• System Architects: Architects designing event-driven systems use UUIDv7 because the ID itself acts as a chronological marker, simplifying the ordering of events across distributed nodes.
• DevOps/SREs: Those managing large-scale cloud databases (like RDS or Cloud SQL) use it to reduce the overhead of index maintenance and vacuuming/reindexing operations.

How is it used?

Implementation is seamless because UUIDv7 maintains the standard 128-bit layout. This means you don't have to change your database schema if you are already using UUIDs; you just change the generation logic in your code.

1. Generation: Instead of picking 128 random bits (like v4), the library captures the current Unix timestamp in milliseconds and appends it to a string of random bits.
2. Transmission: It is transmitted as a standard 36-character string (with hyphens) in JSON payloads, making it compatible with every existing UUID validator.
3. Storage: It is stored in a native UUID column or as BINARY(16). Because it is time-ordered, the database appends new records to the end of the physical index rather than inserting them into random pages.

Is it suitable for databases?

Yes. In fact, it is arguably the most suitable identifier for any relational database that requires global uniqueness.

The problem with random UUIDs is "Index Fragmentation." When you insert a random ID into a clustered index, the database has to move existing data to make room, leading to fragmented pages and terrible write performance. UUIDv7 is monotonically increasing, meaning it behaves like a sequence.

Here is the breakdown by engine:

• PostgreSQL: Perfect. Use the UUID type. UUIDv7 keeps the B-Tree index lean and maintains high insert rates.
• SQL Server: Highly suitable. Use UNIQUEIDENTIFIER. It solves the performance issues associated with NEWID() (which is essentially v4).
• MySQL: Use BINARY(16). For InnoDB, using UUIDv7 as a primary key is a massive win over v4 because it drastically reduces page splits.
• Oracle: Use RAW(16). It integrates seamlessly and provides the same clustering benefits.
• SQLite: Use BLOB. The sequential nature makes it much faster for large datasets.
• Amazon RDS / Azure SQL / Google Cloud SQL: Since these are managed versions of the above, the same rules apply. In cloud environments, reducing random I/O is key to lowering costs and reducing latency.

When was it created, why, and where is it defined?

UUIDv7 was introduced to modernize the UUID standard. While UUIDs have existed for decades, the older versions were either too predictable (v1), too random (v4), or too specialized (v3/v5).

It is defined in the updated IETF standards, specifically within RFC 9562. This RFC replaces the older RFC 4122 to provide a standardized way of implementing time-sorted identifiers. It was created to give the industry a formal, standardized way to handle "lexicographically sortable" IDs without having to rely on third-party, non-standard specifications.

Why was it created?

The primary driver was the need for database locality.

In a distributed world, we can't use a central counter (like an AUTO_INCREMENT column) because that creates a single point of failure and a massive bottleneck. We needed a way to generate IDs on the fly—on different servers in different regions—that would still be "roughly" in order of creation.

By putting the timestamp first, UUIDv7 ensures that IDs generated at the same time are stored physically close to each other on disk. This maximizes cache hits and minimizes the amount of disk head movement required during writes.

Exactly how many bits are random, and why not all 128?

A UUIDv7 consists of 128 bits, partitioned as follows:

• 48 bits are used for the Unix timestamp (milliseconds).
• 4 bits are reserved for the version (set to 0111 to identify it as v7).
• 2 bits are reserved for the variant (identifying it as a standard UUID).
• 74 bits are random (or a mix of randomness and a sequence counter).

Why not all 128? If all 128 bits were random, you would have a UUIDv4. As we've established, total randomness is the enemy of the B-Tree index. The 48-bit timestamp is the "secret sauce" that ensures the ID is sortable.

Is 74 bits of randomness enough? Absolutely. The probability of two IDs being generated in the exact same millisecond on the same node and then sharing the same 74 random bits is mathematically negligible. It provides more than enough entropy for any planetary-scale application.

Is UUIDv7 the new standard?

Yes. For any new project starting today, UUIDv7 should be the default choice for unique identifiers. It essentially deprecates UUIDv4 for use as a primary key. While v4 is still useful for things that must be entirely random (like session tokens), v7 is the new standard for data persistence and identity management.

Is it sortable?

Yes. UUIDv7 is lexicographically sortable.

Unlike UUIDv1, which had a weird bit-shuffling order that made it a pain to sort, UUIDv7 puts the most significant time bits at the very beginning. This means if you sort them as strings or as binary, they will be in the exact order they were created. This allows you to perform range queries (e.g., SELECT * FROM logs WHERE id > '...') without needing a separate created_at index.

Is it suitable for URLs?

Yes, but with the same caveat as all UUIDs: they are verbose. A UUIDv7 is a 36-character string. While it is perfectly safe for URLs (it contains no special characters that require encoding) and it's secure (it prevents ID enumeration), it isn't "short."

If you need extremely short URLs (like a Bitly link), a UUID is too long. But for resource IDs in a REST API (e.g., /api/orders/018ad8...), it is an excellent choice.

Where is it appropriate (or not) to use a UUIDv4?

Appropriate use of UUIDv4:

• Security Tokens: When you need a password reset token or a session ID where knowing the creation time could be a security vulnerability.
• Non-Indexed Fields: When the ID is just a piece of metadata that is never used for sorting or as a primary key.
• Pure Randomness: When the goal is to ensure that there is absolutely no correlation between two IDs.

Inappropriate use of UUIDv4:

• Primary Keys in SQL: As discussed, this is a performance anti-pattern.
• Chronological Data: If you need to know the order of records, v4 is useless.
• High-Volume Writes: In any system where write latency is a KPI, v4's index fragmentation will eventually become a bottleneck.

Comparison to other UUID versions and identifiers

The world of IDs is a balance between entropy, sortability, and standards.

• UUIDv1: Time-based but leaks the MAC address of the server. A huge security risk.
• UUIDv3 & v5: Name-based (MD5/SHA-1). These are deterministic. If you give them the same input, you get the same ID. Not for primary keys.
• UUIDv6: An attempt to make v1 sortable. It's a good bridge, but v7 is the cleaner, modern standard.
• ULID: Very similar to v7 (timestamp + randomness), but uses Base32 encoding. ULID was the pioneer, but v7 is the official RFC standard.
• NanoID: A random string generator. Fast and compact, but lacks a timestamp, meaning it suffers from the same index fragmentation as v4.

Comparison Table

Final Engineering Verdict

If you are designing a system today, stop using UUIDv4 as your primary key.

The a-priori advantage of total randomness is almost never worth the performance penalty of index fragmentation. UUIDv7 gives you everything you need: global uniqueness, distributed generation, and database-friendly sequentiality. It is the most professional way to handle identity in a modern, high-scale architecture.

What is the UUIDv7 Text Layout?

What is the UUIDv7 Binary Layout?