UUID v4 vs v7: which ID format should you use?

UUIDs (Universally Unique Identifiers) give you 128-bit IDs you can create without a central counter. Developers reach for them as primary keys, request IDs, file names, and correlation tokens. The two versions you will see most often today are v4 (random) and v7 (time-ordered). Choosing well affects index health, privacy, and how easy logs are to reason about.

UUID v4: random and familiar

Version 4 fills most bits from a cryptographic random source. Collision risk is negligible for normal application volumes. The upside is simplicity and broad library support. The downside for databases is write locality: random primary keys scatter inserts across B-tree pages, which can increase fragmentation and IO under heavy insert load compared with sequential keys.

Use v4 when you need opaque IDs, do not care about sort order, or are integrating with systems that already expect classic random UUIDs.

UUID v7: time-ordered for databases

Version 7 embeds a Unix timestamp in the high bits so IDs roughly sort by creation time. That makes them friendlier as primary keys: newer rows tend to land near each other on disk. You still get uniqueness from random bits in the remainder of the value.

Trade-offs exist. Time-ordered IDs leak approximate creation time to anyone who can see them. If that metadata is sensitive in your threat model, prefer v4 or another opaque scheme. Also confirm your language and database stack support v7 before standardizing — adoption is growing but not universal yet.

A fixture workflow that does not leak production

When you need IDs for seed data, generate a batch locally, pin them in version control, and never copy IDs from production dumps into public demos. v4 is the safer default for anything that might appear in a screenshot or a support ticket you paste into Slack. v7 is the better default inside a database you control when insert locality matters and leaking approximate create-time is acceptable.

How GenShelf mints each version

On the UUID generator, v4 calls crypto.randomUUID() when the browser provides it; otherwise it fills 16 bytes with crypto.getRandomValues and sets version 4 plus RFC 4122 variant bits. v7 always uses getRandomValues, then overwrites the first 48 bits with Date.now() as a millisecond timestamp (no BigInt), then sets version 7. A batch of up to 100 IDs skips duplicates inside that run only — it is not a claim of uniqueness against other machines.

Formatting is part of the contract. Pick lowercase-with-hyphens unless your stack already standardized on something else. Mixing braces, uppercase, and compact forms in one API is how clients invent bugs. GenShelf’s UUID generator can batch v4 or v7 and match hyphens, case, and braces so fixtures look like your codebase — then download the list instead of retyping.

Practical recommendations

• Default to v4 for public tokens, client-visible IDs, and mixed legacy systems.
• Prefer v7 for high-volume database primary keys when timestamp leakage is acceptable and your stack supports it.
• Do not treat UUIDs as secrets by themselves. If an ID grants access, protect the endpoint with auth — guessing is hard, but leakage still happens via logs and referrers.
• Standardize formatting in APIs (lowercase vs uppercase, hyphens vs compact) so clients do not invent variants.

Generate them locally

When you need a batch for fixtures, migrations, or manual testing, use a free UUID generator that runs in the browser. GenShelf supports v4 and v7 with formatting toggles (hyphens, uppercase, braces) so you can match the style your codebase expects without pasting from random blogs.

For demo datasets, pair UUIDs with realistic placeholder people from the fake name generator so staging screens do not look empty or obviously synthetic.