Why UUID Can Be a Bad Choice for Primary Key in Databases
UUIDs are popular as primary keys: they're unique across systems, safe to generate client-side, and don't leak sequence. But they can hurt database performance and storage. Here's when and why.
Index Size and Randomness
A UUID is 16 bytes (128 bits), often stored as a 36-character string. An INT or BIGINT auto-increment key is 4 or 8 bytes. So UUID primary keys are 2–4× larger. In B-tree indexes, random UUIDs (v4) cause inserts to land in random leaf pages. That leads to index fragmentation: more page splits, slower writes, and a fatter index.
Write Performance
With sequential IDs, new rows append at the end of the table and index. With random UUIDs, the database must find the right page for each new value. Under high insert load, this can slow down inserts and increase I/O. Some databases (e.g. PostgreSQL with uuid_generate_v7() or time-ordered UUIDs) reduce this by making UUIDs more sequential.
When UUIDs Still Make Sense
UUIDs are a good choice when you need: distributed generation (multiple services creating IDs without a central DB), merging data from different sources without ID clashes, or hiding sequence (e.g. no guessable next user ID). In those cases, consider UUID v7 (time-ordered) to get better index behavior than v4, or store UUIDs in a separate column and keep an internal sequential primary key.
Summary
UUIDs as primary keys can increase storage and worsen insert performance due to size and randomness. Use them when cross-system uniqueness or client-side generation matters; otherwise, consider sequential IDs or UUID v7. For generating UUIDs for tests or non-primary-key use, try our bulk generator or single generator.