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

v7:  01a0893e-3c06-71f7-8552-ae98c33654b2
     |------------| |  |  |  |
     48-bit Unix ms timestamp (big-endian)
                    |  |  |
                    version nibble = 7
                       |  |
                       12 bits rand_a (random, or a sub-ms counter)
                          |
                          variant nibble: 8, 9, a or b (top bits 10)
                            remaining 62 bits: rand_b (random)

v4:  7741efb4-e0e2-46a0-af93-7c597611caca
                   ^    ^
        version = 4     variant — all 122 other bits are random

             v1                      v4               v7
timestamp    60-bit, 100 ns ticks    none             48-bit Unix milliseconds, big-endian
random bits  14-bit clock sequence   122              74  (12 rand_a + 62 rand_b)
node id      48-bit MAC or random    none             none
sortable     no (low bits first)     no               yes, by creation time
reveals      host + creation time    nothing          creation time (to the millisecond)
generate     uuid.v1()               crypto.randomUUID()   uuid.v7() / 15 lines of code

-- Postgres 18: both generators are built in
CREATE TABLE events (
  id          uuid PRIMARY KEY DEFAULT uuidv7(),   -- gen_random_uuid() for v4
  kind        text NOT NULL,
  created_at  timestamptz NOT NULL DEFAULT now()
);

-- With v7 the primary-key index already orders rows by creation time,
-- so "latest 100 events" needs no separate created_at index:
SELECT id, kind FROM events ORDER BY id DESC LIMIT 100;

// birthday bound: p ≈ n² / (2 · 2^bits)
const p = (n, bits) => (n * n) / (2 * 2 ** bits);

p(1e9, 122)                            // 9.40e-20   one billion v4 UUIDs
p(1e12, 122)                           // 9.40e-14   one trillion v4 UUIDs
Math.sqrt(2 * 2 ** 122 * Math.LN2)     // 2.72e18    number of v4 UUIDs for a 50% chance

p(1e6, 74)                             // 2.65e-11   a million v7 UUIDs inside one millisecond

const { randomBytes, randomUUID } = require("node:crypto");

randomUUID();   // v4 → "7741efb4-e0e2-46a0-af93-7c597611caca"

function uuidv7() {
  const b = randomBytes(16);                              // in the browser: crypto.getRandomValues(new Uint8Array(16))
  const ts = BigInt(Date.now());                          // 48-bit millisecond timestamp
  for (let i = 0; i < 6; i++) b[i] = Number((ts >> BigInt(8 * (5 - i))) & 0xffn);
  b[6] = (b[6] & 0x0f) | 0x70;                            // version 7
  b[8] = (b[8] & 0x3f) | 0x80;                            // variant 10xx
  const h = b.toString("hex");
  return h.slice(0, 8) + "-" + h.slice(8, 12) + "-" + h.slice(12, 16) + "-" + h.slice(16, 20) + "-" + h.slice(20);
}

const a = uuidv7(), c = uuidv7();
a        // "01a0893e-3c06-71f7-8552-ae98c33654b2"
c        // "01a0893e-3c06-7ada-b536-f18275839206"
a < c    // true — later generation sorts later

new Date(parseInt(a.replace(/-/g, "").slice(0, 12), 16)).toISOString()
// "2026-09-10T02:55:52.326Z"  — the embedded creation time

-- MySQL 8: 16-byte binary column, convert at the edges
CREATE TABLE orders (
  id         BINARY(16) PRIMARY KEY,
  total_cents INT NOT NULL
);

INSERT INTO orders (id, total_cents)
VALUES (UUID_TO_BIN('01a0893e-3c06-71f7-8552-ae98c33654b2'), 4200);

SELECT BIN_TO_UUID(id) AS id, total_cents
FROM orders ORDER BY id DESC LIMIT 10;      -- newest first, straight from the PK

-- UUID_TO_BIN(x, 1) rearranges v1 time fields; leave the flag off for v4 and v7