When to use UUID v4 vs v7
UUID v4 is mostly random. UUID v7 (standardized in RFC 9562) embeds a Unix timestamp in the high bits, which improves locality for many database indexes while remaining wide enough for distributed generation.
Why v4 became the default
Libraries everywhere support it, collision risk is negligible for normal app volumes, and it reveals almost nothing about creation time. The downside is index fragmentation and poorer cache locality when used as a primary key in large insert-heavy tables.
Why teams adopt v7
Time-ordered identifiers insert near the end of B-tree indexes more often, which can reduce page splits. They also make approximate sorting by id meaningful. The trade-off: ids leak creation time roughly at millisecond granularity—unacceptable for some security-sensitive identifiers (think invite tokens), acceptable for many internal row ids.
Decision sketch
| Situation | Lean toward |
|---|---|
| Public capability URLs / secrets | Random (v4) or dedicated token format |
| DB primary keys, high insert rate | v7 or other time-sortable ids |
| Simple scripts and test fixtures | v4 is fine |
Generate fixture ids with the UUID Generator (v4). Choose production formats deliberately in migrations, not by copying test helpers.