A version-7 UUID begins with a 48-bit Unix millisecond timestamp followed by random bits, standardised in RFC 9562. Because the time comes first, v7 UUIDs sort in creation order while keeping the global uniqueness of a UUID.

Why use v7 over v4 for database keys?

Random v4 UUIDs scatter writes across an index and fragment B-trees. The time-ordered prefix of v7 keeps inserts roughly sequential, which improves index locality and write performance.

What is the difference between UUID v4 and v7?

v4 is fully random with no ordering, so consecutive values land all over a database index. v7 puts a 48-bit Unix millisecond timestamp first, so values sort by creation time while the random tail keeps them unique. v7 is the better default for primary keys.

Why is v7 better for database primary keys?

Because the time-ordered prefix keeps new rows inserting near the end of the index rather than scattered throughout it. This reduces B-tree page splits and fragmentation, improving insert throughput and cache locality compared with random v4 keys.

How is a UUID v7 structured?

The first 48 bits are the Unix timestamp in milliseconds, followed by a 4-bit version field set to 7, then 12 random bits, the 2-bit variant, and 62 more random bits — 128 bits in total, formatted as the usual hyphenated hex string.

How is v7 different from a ULID?

Both lead with a millisecond timestamp and sort by time. UUID v7 keeps the canonical 36-character hyphenated hex format used everywhere UUIDs are expected; ULID uses a shorter 26-character Crockford base32 string. Choose v7 for UUID compatibility.

Does a batch of v7 UUIDs stay sorted?

Yes. When you generate many at once, the timestamp is nudged forward for each ID so the whole batch is strictly increasing, even for IDs created within the same millisecond.

What is the UUID v7 Generator?

Free UUID v7 generator — create time-sortable version-7 UUIDs with a millisecond timestamp prefix, ideal for database primary keys. Runs entirely in your browser, nothing is uploaded. It runs free in your browser on Gera Tools, with nothing uploaded.

UUID v7 Generator — Gera Tools

Name: UUID v7 Generator
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Sortable UUID v7 generator

A UUID v7 is the newest standard UUID version, defined by RFC 9562, and is designed to be time-sortable. It leads with a 48-bit Unix millisecond timestamp and fills the rest with cryptographic randomness, so a sequence of v7 UUIDs sorts in creation order while keeping the global uniqueness of a UUID. This combination — the ordering of an auto-increment key with the decentralised uniqueness of a UUID — makes v7 the modern default for database primary keys. This tool generates one ID or a sortable batch, all in your browser.

How it works

The 128 bits are arranged so that time comes first:

Bits	Field	Content
48	Timestamp	Unix time in milliseconds
4	Version	Fixed: 7
12	Random	From Web Crypto
2	Variant	RFC 4122
62	Random	From Web Crypto

Because the timestamp occupies the most significant bits, comparing two v7 UUIDs as strings or bytes orders them by creation time. The random portion (74 bits) comes from crypto.getRandomValues, keeping each value unique. When generating a batch, the timestamp is advanced per ID so the batch stays strictly increasing.

Example

A v7 UUID looks like 018f3a2b-1c4d-7e8a-9b0c-1d2e3f4a5b6c. The leading 018f3a2b-1c4d is the millisecond timestamp, the 7 at the start of the third group marks version 7, and the remaining hex is random. Generate three in a row and their leading characters increase, so they sort in creation order out of the box.

Inserts stay roughly sequential, so indexes don’t fragment the way random v4 keys cause them to. The timestamp and random bits are generated in your browser with Web Crypto, and nothing is uploaded.

Why database index locality matters

When you insert rows with random v4 UUIDs as primary keys, the database index tree (a B-tree in PostgreSQL, MySQL, and most SQL systems) must constantly insert values into arbitrary positions throughout the structure. Each random insert may touch a different index page, pulling that page into memory, modifying it, and writing it back. This creates high write amplification and page fragmentation, particularly on high-insert-rate systems where the index cannot fit entirely in the buffer pool.

With v7 UUIDs, new rows insert near the right edge of the index because timestamps increase monotonically. The page that needs modification is nearly always the rightmost one, which is likely already in the buffer cache from the previous insert. The result is dramatically fewer page splits, better cache utilization, and lower write I/O — the same benefits that make auto-increment integer primary keys so efficient, combined with the global uniqueness and client-side generation that UUIDs enable.

v7 vs ULID: when to choose each

UUID v7 and ULID (Universally Unique Lexicographically Sortable Identifier) solve the same problem — time-ordered, random, client-generated identifiers — with slightly different trade-offs:

Property	UUID v7	ULID
Format	36-char hyphenated hex	26-char Crockford Base32
Database type	Native `uuid` column	`CHAR(26)` or similar
Timestamp precision	Millisecond	Millisecond
Specification	RFC 9562 (IETF standard)	Community spec
Canonical sorting	Yes, by string	Yes, by string

If your database, ORM, or API already expects UUID format (the 36-char hyphenated string), v7 is the drop-in upgrade from v4 with no format change. If you are starting fresh and want a more compact identifier that avoids hex, ULID is worth considering. Most teams using UUIDs in existing systems choose v7 because it requires zero schema changes.

Adoption and ecosystem support

UUID v7 was standardised in RFC 9562 in May 2024, so ecosystem support is still growing but already broad. PostgreSQL 17 generates v7 UUIDs natively with gen_random_uuid_v7(). Major ORM libraries for JavaScript, Python, Java, and Go have added v7 support. New API designs increasingly default to v7 over v4 for resources with natural time ordering (posts, events, transactions). If you are choosing an identifier strategy for a new service, v7 is now the well-supported, standards-backed choice for time-sortable identifiers.