UUID v1 vs UUID v4
The original time-based UUID (v1) versus the random UUID (v4) — and why the modern answer is "use neither if you can."
Side-by-side comparison
| Property | UUID v1 | UUID v4 |
|---|---|---|
| Source bits | 60 timestamp + 14 clock seq + 48 node | 122 random |
| Reveals creation time | Yes (100ns precision) | No |
| Reveals node / hardware | Originally MAC; modern impls use random | No |
| Lexically sortable | No (use v6 for that) | No |
| Best fit | Legacy systems, CDR/event correlation | Public IDs, tokens, file names |
Why v4 won the popularity contest
UUID v1 was the original RFC 4122 design and is still what PostgreSQL's legacy uuid_generate_v1() function produces. But three things made v4 dominant in modern code: (1) it requires no clock or hardware state, just a CSPRNG; (2) it leaks nothing about the generating machine; (3) random IDs are trivially deterministic to test against. RFC 9562 keeps v1 for backward compatibility but introduces v6 and v7 as the modern time-based choices.
Frequently asked questions
Neither — for new applications, the modern choice is v4 (random) for unguessable IDs and v7 (time-ordered, RFC 9562) for sortable database keys. v1 has been largely superseded by v6 and v7. Use v1 only when you must interoperate with an existing v1-based system.