You need a unique identifier. Your first instinct is UUID v4 -- random, 128 bits, practically unique. But if you're using it as a database primary key, you might be making a mistake.
UUID v4 (random): 122 random bits + 6 version/variant bits. Universally unique, no coordination needed. But random UUIDs are terrible for B-tree indexes. Inserting random values into an indexed column causes page splits, index fragmentation, and cache misses. On a large PostgreSQL table with a UUID primary key, random insertion can be 3-5x slower than sequential insertion.
UUID v7 (time-ordered): 48-bit Unix timestamp + 74 random bits. The timestamp prefix means values sort chronologically. Inserts go to the end of the index. B-tree stays compact. Performance is close to auto-increment integers with the distribution benefits of UUIDs. PostgreSQL 17 added built-in uuid v7 generation via gen_uuid_v7().
When to use v4: Client-generated IDs where you can't guarantee clock accuracy. Offline-first apps. Distributed systems where time synchronization is unreliable.
When to use v7: Server-generated database primary keys. Event sourcing where chronological ordering matters. Any system where insert performance on indexed UUID columns is a concern.
When to avoid both: If you don't need universal uniqueness, a simple auto-increment integer is faster and smaller (4 vs 16 bytes). Use the right tool for the job.
Use our UUID generator to create both versions and compare them side by side.