UUID Generator (v4 and v7)

The text form is 32 hexadecimal digits split into five groups of 8-4-4-4-12 characters. Two positions carry metadata rather than data. The first digit of the third group is the version, and the first digit of the fourth group holds the variant. For standard UUIDs the variant bits are 10, so that digit is always 8, 9, a or b.

017f22e2-79b0-7cc3-98c4-dc0c0c07398f
└──────┬────┘ │    │
 48-bit Unix  │    └─ variant: 9 = 1001, top bits "10"
 time in ms   └────── version: 7

In a v4 UUID, the remaining 122 bits are random. In a v7 UUID, the first 48 bits are the Unix time in milliseconds, which is why the inspector can turn 017f22e2-79b0-… back into 2022-02-22T19:22:22.000Z (try it with the epoch converter too: 0x017f22e279b0 is 1645557742000). The other 74 bits are random. Two special values exist as well: the Nil UUID, which is all zeros, and the Max UUID, which is all f. They work as sentinels such as "not set" or "upper bound", and they have no version.

The format is defined by RFC 9562, published in May 2024. It replaces RFC 4122, adds versions 6, 7 and 8, and formally defines the Max UUID.

Most databases store primary keys in a B-tree index. When keys are random, as in v4, every insert lands on a random leaf page. Once the index is bigger than memory, inserts keep pulling cold pages from disk, pages split half-full, and the write-ahead log grows. A v7 key always sorts after the previous one, so new rows are appended to the right-most leaf page, just like an auto-increment integer. The hot part of the index stays small and cached, which matters most on MySQL/InnoDB and SQL Server, where the table itself is clustered on the primary key.

Use v4 when the ID must reveal nothing, for example a password-reset token or a public identifier where creation time is sensitive. Use v7 for row IDs, event IDs and anything you will range-scan or sort by time. Keep in mind that anyone who can see a v7 ID can read its creation timestamp.

How likely is a v4 collision?

With 122 random bits there are 2¹²² ≈ 5.3 × 10³⁶ possible values. By the birthday bound, the chance of at least one duplicate among n UUIDs is roughly n² / 2¹²³. A billion UUIDs give a probability of about 10^-19. You need about 1.03 × 10¹⁴ UUIDs (103 trillion) to reach a one-in-a-billion chance, and about 2.7 × 10¹⁸ for a 50% chance. That is a billion per second for 86 years. In practice, a broken random number generator, such as a forked process that reuses a seeded PRNG state, is a far more realistic cause of duplicates than the math.

Auto-increment IDs are compact and fast, but they need a round trip to the database before you know the ID, they collide when you merge shards, and sequential public IDs let anyone enumerate /orders/1001, /orders/1002 and so on. ULID solved the sortable-ID problem before RFC 9562 existed. It uses the same 48-bit millisecond timestamp followed by 80 random bits. UUID v7 gives you the same ordering in a format that every UUID column, library and validator already accepts, so it is usually the better default for new systems.

Storing the 36-character string in a VARCHAR(36) more than doubles the size of every key and every index that references it, and comparisons become string collation work. Store the 16 raw bytes instead:

-- PostgreSQL: native 16-byte type (PostgreSQL 18 also adds uuidv7())
CREATE TABLE orders (
    id uuid PRIMARY KEY,
    created_at timestamptz NOT NULL DEFAULT now()
);

-- MySQL 8: BINARY(16) with conversion helpers
CREATE TABLE orders (id BINARY(16) PRIMARY KEY);
INSERT INTO orders VALUES (UUID_TO_BIN('017f22e2-79b0-7cc3-98c4-dc0c0c07398f'));
SELECT BIN_TO_UUID(id) FROM orders;

Do not pass the swap flag (UUID_TO_BIN(x, 1)) for v7 values. The flag reorders the time fields of v1 UUIDs, while v7 is already in time order and swapping would scramble it. If an API returns UUIDs inside JSON payloads, the JSON formatter makes long arrays of them easier to read.