The perils of UUID primary keys in SQLite

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.

	▲	bob1029 an hour ago \| parent [-]
		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.

▲

w10-1 32 minutes ago | parent | prev | next [-]

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?

▲

dumbledorf 3 hours ago | parent | prev | next [-]

Wait how is sqlite doing a million inserts a second?

	▲	smitty1e 2 hours ago \| parent \| next [-]
		':memory:' https://sqlite.org/inmemorydb.html
	▲	JSR_FDED an hour ago \| parent \| prev \| next [-]
		In batches
	▲	kg 2 hours ago \| parent \| prev [-]
		sqlite is really fast. I'm surprised it's only a million.

▲

yepyoukno 3 hours ago | parent | prev [-]

Perils of “UUIDv4”. Everyone knows that’s what UUIDv7 was really for, and you should always convert that to binary to optimize everything.

▲

JSR_FDED an hour ago | parent [-]

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.

	▲	yepyoukno an hour ago \| parent [-]
		Oh yes, I meant don’t store as an ID in its string format!