UUID Generator

Choosing UUID v4 or v7

Use v4 when you need an opaque random identifier, such as a correlation ID, idempotency key or filename. Consider v7 for a database key when insertion order matters. Its leading timestamp makes new values sort by creation time, but it also reveals when the ID was created.

How random UUIDs affect database indexes

A v4 UUID contains 122 random bits. Consecutive values can land at unrelated positions in a B-tree index instead of near its right edge. On write-heavy indexed tables, that pattern can increase:

• Page splits. An insert into a full interior index page can split the page and leave unused space in both resulting pages.
• Index size. Lower page occupancy can make the index larger than one built from sequential values.
• Cache misses. Inserts distributed across the index may touch more pages than inserts concentrated near one edge.

The effect depends on table size, write rate, cache and database engine. It can matter more in MySQL InnoDB, where the primary key controls clustered row order, than in PostgreSQL, where heap storage is separate from the index.

What v7 changes

UUID v7 places a 48-bit Unix millisecond timestamp in the leading bits and uses the remaining fields for version, variant and random or monotonic data. It remains a 128-bit UUID and sorts broadly by creation time, which gives index inserts more locality than v4.

v4:  9f8d1c47-3b2e-4a15-9c6d-8e7f0a1b2c3d   ← nothing sortable
     b1e05c92-7d4a-4f68-a2b1-5c9e3d7f8a0b   ← lands somewhere else entirely

v7:  019512a3-4f80-7c21-9d3e-1a2b3c4d5e6f   ← 019512a3-4f80 is the timestamp
     019512a3-5b1c-7e04-8f2a-6b7c8d9e0f1a   ← next insert sorts after it

UUID v7 values can still be generated without a database sequence or coordination between services, and they do not expose a simple row count. This generator uses a counter within the same millisecond so values produced in one batch remain ordered.

UUID v4 collision probability

A v4 UUID has 122 random bits after its version and variant bits are fixed. The birthday bound reaches a 50% chance of at least one collision after roughly 2.7 quintillion generated values. At one million values per second, reaching that count would take about 85,000 years.

That probability assumes a cryptographically secure random source. Math.random() is not suitable because its entropy and predictability depend on the implementation. This tool uses crypto.randomUUID() when available and crypto.getRandomValues() as its fallback.

Storing UUIDs efficiently

A UUID contains 16 bytes, while its canonical text form uses 36 characters. A native UUID type or 16-byte binary column uses less index and row storage than VARCHAR(36) and avoids text collation during comparison.

Generating UUIDs in your own code

// Browser API available since 2021
    // Requires HTTPS or localhost
const id = crypto.randomUUID();

    // Node API
import { randomUUID } from 'node:crypto';
const id = randomUUID();

-- PostgreSQL 13+ generates v4
SELECT gen_random_uuid();

    -- PostgreSQL 18+ includes v7
SELECT uuidv7();

    -- MySQL 8+ generates v1 rather than v4
SELECT UUID();

import uuid
    uuid.uuid4()          # Creates a random UUID
    str(uuid.uuid4())     # Converts to canonical text