Guides · Updated 2026-10-23

UUID v4 vs v7: which one should you use?

For a decade the answer to “which UUID?” was simply v4: 122 random bits, no coordination, no collisions in practice. Then RFC 9562 (2024) standardised UUID v7, which puts a millisecond timestamp in front of the random bits — and suddenly the default for new database schemas changed.

This guide explains what actually differs between the versions, why it matters for your indexes, and the cases where v4 is still the better choice. Generate any of them while you read with the free UUID generator — v1, v4 and v7, up to 1,000 at once, with a decoder that shows the timestamp hidden inside v1 and v7 ids.

What is inside a UUID

Every UUID is 128 bits written as 32 hex digits in five groups: 017f22e2-79b0-7cc3-98c4-dc0c0c07398f. Two places are fixed: the first digit of the third group is the version (the 7 above), and the first digit of the fourth group encodes the variant (8, 9, a or b for standard UUIDs). Everything else depends on the version:

v1 — a 60-bit timestamp in 100-nanosecond ticks since 1582, a clock sequence and a 48-bit node id that was traditionally the machine’s MAC address. The timestamp is split into shuffled fields, so v1 ids do not sort by time.
v4 — 122 random bits. Nothing else.
v7 — a 48-bit Unix timestamp in milliseconds first, then 74 random (or counter) bits. Sorting v7 ids as strings or bytes sorts them by creation time.

Paste any UUID into the decoder on the UUID generator to see its version, variant and, for v1 and v7, exactly when it was made.

Why v7 makes better primary keys

Databases store primary keys in a B-tree index. With random v4 keys, each insert lands at a random position in that tree: pages split all over the index, recently written rows are scattered across disk, and the working set the cache must hold grows with the whole table. On large, write-heavy tables this shows up as slower inserts, bloated indexes and more I/O.

v7 keys arrive in order, so new rows append to the right-hand edge of the index exactly like an auto-increment integer would — while keeping everything that made UUIDs attractive:

ids can be generated anywhere (client, service, offline device) with no round-trip to the database;
they are unique across tables, shards and merged datasets;
they do not reveal how many rows you have, unlike sequential integers.

As a bonus, “newest first” becomes ORDER BY id DESC, and keyset pagination works on the primary key alone.

When random v4 is still the right choice

v7’s strength — the embedded timestamp — is also its weakness. Anyone who sees a v7 id can read when the record was created, to the millisecond. Prefer v4 when:

the id is public and creation time is sensitive — invitation links, password-reset tokens, user ids in URLs where signup dates should stay private;
you need unpredictability: v7 has fewer random bits, and ids made in the same millisecond are close together;
the table is small or read-mostly, so index locality does not matter.

A common pattern is both: a v7 primary key internally, and a separate random v4 (or a longer random token) for anything exposed outside. And never use any UUID as a secret on its own — for tokens, generate 128+ random bits specifically for that purpose, the same way the password generator draws from the browser’s secure random source.

Storing and generating UUIDs efficiently

The storage format matters as much as the version:

Use a native 16-byte type — uuid in PostgreSQL, BINARY(16) in MySQL (with UUID_TO_BIN()), uniqueidentifier in SQL Server. A CHAR(36) column is more than twice the size, and every index that includes the key pays for it again.
Generate v7 in the database or the app. PostgreSQL 18 ships a built-in uuidv7() function; Python 3.14 added uuid.uuid7(); in JavaScript, crypto.randomUUID() gives v4 and the uuid npm package provides v7().
Keep the canonical lowercase hyphenated form in APIs and logs. Uppercase or braces ({…}) are display conventions from the Windows/.NET world, where UUIDs are called GUIDs.

-- PostgreSQL 18
CREATE TABLE orders (
  id uuid PRIMARY KEY DEFAULT uuidv7(),
  created_at timestamptz NOT NULL DEFAULT now()
);

Need test fixtures? The generator exports a whole batch as a quoted, comma-separated list ready to paste into SQL or a JSON seed file — and the JSON Schema generator tags UUID strings with format: uuid automatically.

Generate v4 or v7 UUIDs free — up to 1,000 at once

Frequently asked questions

Should I use UUID v4 or v7 for a primary key?

Use v7 for new database primary keys: it is time-ordered, so inserts append to the index instead of scattering across it, and it keeps every other UUID advantage. Use v4 where the id is public and its creation time should stay private.

Can UUID v7 values collide?

Practically never. Each v7 id carries 74 random or counter bits per millisecond, and well-behaved generators also count upward within a millisecond, so ids from one generator are strictly increasing and unique.

Is UUID v7 an official standard?

Yes. RFC 9562, published in May 2024, defines versions 6, 7 and 8 and replaces the original RFC 4122. v7 is the version the RFC recommends for new time-based ids.

How do I generate UUIDs online for free?

Open code.doaide.com/tools/uuid-generator, pick v4, v7 or v1 and how many you need (up to 1,000), and copy or download them. They are generated in your browser with a cryptographically secure random source and never sent anywhere.