The perils of UUID primary keys in SQLite(andersmurphy.com)
25 pointsby emschwartz4 hours ago5 comments
  • pyuser583a few seconds ago
    Oh gosh the ints v uuids debate for pks. This is worse than vim v eMacs or brackets v braces.
  • blopker2 hours ago
    UUIDs are way over used. There is almost always a better key to use, usually a bigint for databases. If you're making some kind of leaderless distributed data store, then maybe, but even then there are other ID sharding strategies I'd go for first depending on the constraints.

    For a single database, bigints are smaller and faster, with less footguns.

    UUIDs can be nice for an opaque public ID, however I'd still prefer something like a Sqid for space and usability.

    • Fabricio209 minutes ago
      > bigints are smaller and faster, with less footguns

      But be careful!! Javascript WILL interpret your bigints as Number() and round them down because they are too big without telling you!!!

      Famously seen by every snowflake user that has interacted with Javascript, quite an annoying problem.

    • crubier12 minutes ago
      No one ever got fired for using UUIDs
    • JamesSwift33 minutes ago
      UUIDs also have a nice benefit of it being impossible to query the wrong table with one if you mixup what an FK goes to
    • bob10292 hours ago
      I am finding UUIDs help a lot if your primary schema consumer is an LLM.

      Inappropriate aliasing of integer keys allows for silent errors in queries because it will actually return some result a lot of the time. A UUID is immune to this problem. The model recognizes its mistake a lot more reliably when previously non-empty tables start showing up empty after attempting a join.

    • 2 hours ago
      undefined
  • w10-1an hour ago
    Isn't the solution just to use the rowid (after doing the read-id-after-insert dance)?

    How much trouble does SQLite reysing rowid's actually cause?

  • dumbledorf3 hours ago
    Wait how is sqlite doing a million inserts a second?
  • yepyoukno3 hours ago
    Perils of “UUIDv4”. Everyone knows that’s what UUIDv7 was really for, and you should always convert that to binary to optimize everything.
    • JSR_FDED2 hours ago
      Small nit: uuid7 is 128 bits (16 bytes) by definition. So there’s no need to convert it to binary. It already is. Unless you’re working with a stringified version of the uuid7.
      • yepyoukno2 hours ago
        Oh yes, I meant don’t store as an ID in its string format!
        • dexterdog16 minutes ago
          It's just s dumb as storing dates as strings, but people still do it.