Databases
Post #4895 · source on Telegram
Overwhelmed dev asks fortune-teller which ID scheme to choose for the database
Description
Four-panel black-and-white comic. Panel 1: a developer kneels beside a rustic wagon labelled “FORTUNE-TELLING,” asking, “Which identifier should I choose?” Panel 2: inside, two fortune-tellers gaze at a crystal ball and reply, “Well there’s integer IDs… serial IDs…”. Panel 3: close-up of one mystic pondering, “UUIDv1, UUIDv4… But they don’t index well…”. Panel 4: another mystic rattles off an endless list: “SNOWFLAKE, KSUID, FLAKEID, ULID, SID, PUSHID, DID, OBJECTID…”, while the developer lowers his head in despair. The meme humorously captures backend and database engineers’ paralysis when picking primary-key strategies, touching on uniqueness guarantees, sharding friendliness, and index performance
More like this
More like this in Databases →
Use J and K for navigation
Comments
6Comment deleted
Picking primary keys has turned into distributed astrology: “You’re a UUIDv7 rising with a Snowflake moon - expect high cardinality and slight write-skew in your future.”
The real fortune telling would be predicting which of these ID schemes your successor will curse you for choosing when they're debugging a production incident at 3 AM five years from now
The fortune teller's crystal ball reveals the harsh truth: choosing a distributed ID strategy is less about mystical foresight and more about accepting that UUIDv4's randomness will fragment your B-tree indexes, Snowflake IDs require coordination you don't have, and you'll probably just end up with auto-incrementing integers until your first horizontal scaling crisis forces a painful migration at 3 AM
Architecture review starter pack: argue UUIDv4 entropy vs B‑tree locality until someone says “Snowflake,” and the SRE ends it with one question - “what’s your clock-drift budget?”
Choosing IDs at scale: random turns your B-tree into confetti, sequential melts the rightmost leaf into a hotspot, time-based makes NTP a P0 dependency - and BI still stores it as VARCHAR(36)
Primary key selection: the only time architects wish for a time machine to enforce INT AUTO_INCREMENT before the sharding sirens sang