Question 1

What's the difference between UUID v4 and UUID v7, and which should I use?

Accepted Answer

UUID v4 and UUID v7 serve fundamentally different purposes despite both being 128-bit identifiers. UUID v4 (RFC 9562 §5.4) is generated from 122 random bits — every possible v4 UUID is equally likely, with no ordering or relationship between sequentially generated values. This makes v4 ideal for security-sensitive contexts (session tokens, CSRF tokens, API keys) where unpredictability is the priority. The downside: random UUIDs cause B-tree index fragmentation in databases because each insert lands at a random position in the index, leading to page splits and degraded write performance at scale. UUID v7 (RFC 9562 §5.7) solves this by embedding a Unix timestamp (millisecond precision) in the first 48 bits, followed by random bits for uniqueness. Because the timestamp portion is monotonically increasing, sequentially generated v7 UUIDs sort roughly in creation order. For databases: use v7 as primary keys — they preserve B-tree index locality, reducing page splits by ~90% compared to v4 in high-throughput OLTP workloads. For security tokens: use v4 — the full randomness prevents an attacker from guessing the next value. jslet's generator supports both, with bulk mode (up to 500 at once) for seeding test databases.

Question 2

Should I use UUID v7 as a database primary key instead of auto-increment integers?

Accepted Answer

UUID v7 primary keys offer a compelling middle ground between auto-increment integers and random UUID v4. Advantages over auto-increment integers: (1) No central sequence coordination — multiple application servers and microservices can generate IDs independently without collisions, eliminating the single-writer bottleneck and the need for distributed sequence generators. (2) No ID enumeration vulnerability — an attacker can't guess the next record by incrementing the ID (GET /users/1042 → GET /users/1043), making UUIDs preferred for public-facing API endpoints. (3) Multi-region writes — two database regions can insert concurrently without ID conflicts. Advantages over UUID v4: the timestamp prefix in v7 means new rows cluster together in B-tree indexes, giving near-sequential insert performance rather than the random-scatter penalty of v4. The trade-off: UUIDs are 128 bits (16 bytes) vs 64 bits (8 bytes) for bigint — roughly double the storage per row, and the larger key propagates to every secondary index and foreign key reference. For most OLTP workloads at moderate scale, UUID v7 is the best default choice — it's the first UUID version that doesn't force you to choose between distributed generation and index performance.

Question 3

How do I generate multiple UUIDs at once for testing or database seeding?

Accepted Answer

Most UUID generators force you to click 'Generate' once per UUID, which is impractical when you need dozens or hundreds of identifiers for test fixtures, database seed scripts, or mock API responses. jslet's UUID Generator solves this with a bulk mode: set the count to any number between 1 and 500, choose v4 or v7, and click Generate. All UUIDs appear in a scrollable list instantly. You can copy them in three formats: (1) Newline-separated — one UUID per line, paste directly into a SQL VALUES clause or a text file, (2) JSON array — ["uuid1", "uuid2", ...] for use in JavaScript/TypeScript test files or API mock data, (3) CSV — for importing into spreadsheet tools or database GUIs. For database seeding specifically: use UUID v7 for primary key columns to get time-ordered inserts. The bulk count limit of 500 is designed to cover the most common test data scenarios without overwhelming the browser — generating 500 cryptographically random UUIDs happens in under 50ms. For larger batches, make multiple 500-UUID calls.

🟢📖 UUID v4 vs v7 — Which Should You Use?