UUID v4 vs v7: Which to Use and How to Bulk Generate
Published July 14, 2026By Samson PG
Random v4 UUIDs are fine for most IDs. Time-ordered v7 helps indexes. Generate either in bulk without a server round-trip.
A UUID is a 128-bit identifier, usually shown as 36 characters with hyphens. UUID v4 is random (with version/variant bits set). UUID v7 embeds a Unix timestamp so values roughly increase over time — friendlier for B-tree indexes than pure random keys.
v4 vs v7 at a glance
| Version | Ordering | Typical fit |
|---|---|---|
| v4 | None (random) | Tokens, client IDs, “just need unique” |
| v7 | Time-sortable | Primary keys, event logs, sync queues |
v4 collisions are astronomically unlikely at normal volumes. v7 adds sortability but can leak approximate creation time — usually acceptable for internal IDs, less ideal if opacity matters.
Bulk generation tips
- Generate only what you need; avoid mega-lists you will never use.
- Keep one format: with hyphens vs compact hex, uppercase vs lowercase — be consistent in APIs.
- Do not treat UUIDs as secrets; they identify, they do not authenticate.
Generate with TryDevSnip
TryDevSnip UUID Generator creates UUIDs in your browser so test fixtures and local scripts do not depend on an online ID service. Bulk output is handy for seed data and load-test payloads.
Privacy one-liner: generation runs on-device; not uploaded to our servers for processing.
Related: Password Generator when you need secrets, not IDs; Hash Generator when you need digests.
FAQ
Should new Postgres tables use v7?
Often yes for primary keys if you want better insert locality than v4. Confirm library support (uuidv7) in your stack.
Is crypto.randomUUID() always v4?
In browsers and modern Node, yes — RFC 4122 version 4.
Can I sort v4 UUIDs by creation time?
No. Lexicographic sort of v4 strings is meaningless for time. Use v7 or a separate created_at column.
Are NIL and max UUIDs useful?
Sometimes as sentinels in protocols. Do not use them as real entity IDs in production rows.