UUID v4 vs UUID v7: Which Should You Use for Database Keys?

UUIDs (also called GUIDs) are 128-bit identifiers you can generate anywhere — on a client, in a worker, on a disconnected device — without coordinating with a central database. For years the default answer was version 4: just random bits. RFC 9562, published in 2024, standardized version 7, and it has quickly become the recommended choice for database keys. Here's why, and when v4 is still right.

How the bits are laid out

UUIDv4:  xxxxxxxx-xxxx-4xxx-Yxxx-xxxxxxxxxxxx
         └──────── 122 random bits; "4" = version, Y ∈ {8,9,a,b} = variant

UUIDv7:  tttttttt-tttt-7xxx-Yxxx-xxxxxxxxxxxx
         └─ 48-bit Unix time (ms) ─┘ └── 74 random bits (+ version/variant)

Because the timestamp sits in the most significant bits, UUIDv7 values compare in time order whether you sort them as strings, bytes or native UUIDs. You can read the creation time straight out of one:

01a16d3e-e1c0-7c41-9f3d-2b6e8c41a5d0
└ first 12 hex digits = 0x01a16d3ee1c0 = 1792834200000 ms
                      = 2026-10-24 09:30:00.000 UTC

Side by side

Why v7 is faster as a primary key

Most databases store primary keys in a B-tree index, kept in sorted order. With random v4 keys, each insert lands at a random position in the tree. Once the index is larger than memory, that means:

• Random I/O — each insert may need a different index page read from disk.
• Page splits — full pages split in the middle, leaving pages half empty and the index bloated.
• Poor cache use — the "hot" set of pages is the entire index.
• Write amplification — in Postgres, more pages touched means more full-page images in the write-ahead log.

With v7, new keys are always larger than recent ones, so inserts go to the right edge of the index — the same access pattern as an auto-increment integer. Pages fill up completely, the working set stays small, and recently created rows (usually the most queried) sit near each other. Benchmarks routinely show substantially faster bulk inserts and smaller indexes compared with v4 once tables grow beyond memory.

You also get a free, coarse created-at ordering: ORDER BY id returns rows roughly by creation time, and keyset pagination (WHERE id > $last ORDER BY id LIMIT 50) works naturally.

Will they collide?

For v4, the birthday bound puts a 50% chance of a single duplicate at about 2.7 × 10¹⁸ IDs — generating a billion per second, that takes 86 years. For v7, the 74 random bits only need to be unique among IDs created in the same millisecond; a 50% collision chance needs about 1.6 × 10¹¹ IDs in one millisecond. Neither will happen in practice, provided the generator uses a cryptographically secure random source. (Most real-world UUID collisions trace back to bad randomness — cloned VMs or seeded PRNGs — not to the math.)

When to stick with v4

• Public identifiers where timing is sensitive. A v7 ID in a URL reveals exactly when a user signed up, an order was placed or a document was created. That may leak business volume or personal information.
• IDs that must not be correlated. Sequential timestamps make it easier to link records created together.
• Systems that don't benefit from ordering — small tables, hash-indexed stores, or identifiers that are never indexed.

A common hybrid: use UUIDv7 as the internal primary key, and expose a separate random identifier (v4 or a short random slug) in public URLs.

Generating UUIDv7 in practice

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

-- Extract the embedded timestamp
SELECT uuid_extract_timestamp(id) FROM orders LIMIT 1;

// Browsers & Node have v4 built in:
crypto.randomUUID();            // e.g. "3b241101-e2bb-4255-8caf-4136c566a962"

// For v7, use the 'uuid' package (v10+):
import { v7 as uuidv7 } from "uuid";
uuidv7();                        // e.g. "019a1a3c-7b2e-7c41-9f3d-2b6e8c41a5d0"

import uuid
uuid.uuid4()   # random
uuid.uuid7()   # time-ordered — Python 3.14+

Store UUIDs in a native uuid column (Postgres) or BINARY(16) (MySQL), not as 36-character strings — that's 16 bytes instead of 36+ and much faster comparisons. To generate a batch in your browser, use our UUID generator, which produces both v4 and v7 from the browser's secure random source.

What about ULID, Snowflake and v1/v6?

• ULID — the community predecessor of v7: also 48 bits of milliseconds plus 80 random bits, written as 26 Crockford Base32 characters. Fine if you already use it; v7 is now the standardized equivalent and fits native UUID columns.
• Snowflake IDs — 64-bit time-ordered integers (Twitter, Discord). Smaller, but need a coordinated worker ID per generator.
• UUIDv1 / v6 — time-based with a node ID that was historically the machine's MAC address, which leaks hardware identity. v6 is a re-ordered v1 kept for legacy migration; RFC 9562 recommends v7 for new systems.
• UUIDv8 — a vendor-defined format for custom layouts.