UUID v4 vs v7: which should you use?

How they differ

A UUID v4 is 122 random bits plus 6 fixed bits that mark the version and variant. Nothing in it means anything.

A UUID v7 starts with a 48-bit timestamp: the number of milliseconds since 1 January 1970, UTC. The rest is random, apart from the same version and variant bits. Because the time comes first, v7 IDs made later sort after IDs made earlier.

Both are equally unique in practice. The random part of a v7 is smaller, but it only has to be unique among IDs made in the same millisecond.

Why v7 is kinder to databases

Most databases keep a primary key index as a B-tree. A B-tree stores keys in sorted order across fixed-size pages.

With v4, each new key is random, so it belongs at a random spot in the index. The database has to find and change a different page for almost every insert. Pages fill up in the middle and split, and the whole index has to stay in memory to stay fast. On large tables this shows up as slower inserts and a bigger index.

With v7, each new key is a little larger than the last one. New entries go onto the last page, much like an auto-increment integer. The pages you are writing to stay in memory, and pages fill up neatly before a new one starts.

This matters even more in MySQL’s InnoDB, which stores the table rows themselves in primary key order. It also gives you a free bonus: ORDER BY id returns rows in roughly the order they were created.

When v4 is still the better choice

The ID is public and the creation time is private. Anyone can read the timestamp out of a v7. If your IDs show up in URLs or API responses, a v7 tells people when an account, order or document was created. Read how to get the timestamp from a UUID v7 to see how easy it is.

Your database wants writes spread out. Some distributed databases, such as Google Cloud Spanner, split tables by key range across servers. Keys that always increase send every new row to the same server. Random v4 keys spread the load.

Ordering does not matter. For small tables, cache keys, file names or message IDs that are only ever looked up exactly, v4 is simpler and supported everywhere.

A common pattern is to use both: v7 as the internal primary key, and a separate random v4 as the public ID.

Generate them in code

// v4: built into browsers and Node.js
const a = crypto.randomUUID();

// v7: npm install uuid
import { v7 } from 'uuid';
const b = v7();

import uuid

a = uuid.uuid4()
b = uuid.uuid7()  # Python 3.14 and later

SELECT gen_random_uuid();  -- v4
SELECT uuidv7();           -- v7, PostgreSQL 18 and later

var a = Guid.NewGuid();          // v4
var b = Guid.CreateVersion7();   // v7, .NET 9 and later

Good to know