so here is the rule of thumb:
auto-increment: for local development & simple internal tables
UUIDv4: for strict security, session tokens, and total opacity
UUIDv7: for production databases and massive insertion performance
every architecture has trade-offs
choose wisely
because the first 48 bits are a timestamp,
UUIDv7 naturally sorts chronologically
time only moves forward
so when a new UUIDv7 arrives at the database,
it doesn't force its way into the middle of the B-Tree
it just effortlessly stacks at the very end
the fix?
we don't abandon UUIDs
we surgically change their anatomy
enter UUIDv7
instead of 122 bits of pure chaos, UUIDv7 splits the string.
it takes the first 48 bits and replaces them with a Unix timestamp (down to the millisecond)
the rest stays random
since UUIDv4 is 100% pure randomness
when a new UUID record arrives,
it doesn't neatly append to the end
it gets forcefully squeezed randomly into the middle of the sorted list
this forces the database to constantly split and shift memory
this kills insertion performance,
to index primary key, database uses B-tree data structure
firstly PK column is sorted value wise,
then seperate memory is alloted for that sorted values
and the memory values point to the exact values in the column
in auto-increment, the values are already sorted incrementally
to know why UUID v4 breaks performance,
understand why databases index primary keys in the first place
imagine finding one specific name in a 10,000-page book, without an index
you have to read every single page
an index sorts the data so the database can find it instantly
we know the math,
we know the anatomy
it seems like the ultimate, decentralized primary key
you can generate them offline forever without a collision
if you actually use this standard UUID (v4) in your database,
it will secretly destroy your performance
the hyphens in a UUID aren't just for readability.
they divide the string into a strict 8-4-4-4-12 format
this structure acts like a map,
letting systems instantly spot the metadata
like the version and variant hiding in plain sight:
UUIDs are Hexadecimal (Base-16)
instead of 10 combinations per character,
you get 16 (0 to 9 + a to f)
the math isn't 10 × 10, it's 16 × 16
for a 32-character string,
the total uniqueness jumps from 10³²
all the way to 16³² -(5.3 undecillion)
