The perils of UUID primary keys in SQLite (andersmurphy.com)

submitted 16 hours ago by cm0002@suppo.fi to c/programming@programming.dev

21 comments fedilink hide all child comments

all 22 comments

sorted by: hot top controversial new old

[-] eager_eagle@lemmy.world 18 points 15 hours ago* (last edited 14 hours ago)

It's weird their main reason is performance, but then proceed to benchmark SQLite. Who's inserting 10s of millions of records per minute on sqlite?

Even in production, client-server DBMSs, I'd wager that there are plenty of other things that dominate performance before you even get near your choice of a primary key, so it probably doesn't matter until you get a large enough throughput in your database.

[-] SmoothLiquidation@lemmy.world 4 points 13 hours ago

I would say their findings would be pretty consistent no matter which DBMS you use.

[-] eager_eagle@lemmy.world 7 points 13 hours ago* (last edited 13 hours ago)

But that's the thing with benchmarks, you run them because making assumptions about performance based on guesswork often fails. SQLite is very much architecturally unique for being a daemon-less database that doesn't concern itself with concurrent writes.

Is UUID as pk slower than int or bigints? Probably - you're storing 4x more data than a 32-bit integer. Does it matter? Probably not.

[-] Tja@programming.dev 2 points 12 hours ago

UUID could be slower for SQLite. If you have a SEQUENCE and millions of concurrent writes you have other problems.

[-] TehPers@beehaw.org 7 points 13 hours ago

I'm glad this covers UUIDv7. Unless you need cryptographically-random, unpredictable row IDs, using UUIDv7 helps a lot with the performance by making the keys ordered at least.

[-] ghodawalaaman@programming.dev -4 points 15 hours ago

awesome!

but seriously who uses UUID as their primary keys? what's wrong with plain old INT. it's more predictable you can look at the integer primary key and tell which records created when relative to each other. also you can easily remember them. unlike UUID.

[-] x00z@lemmy.world 16 points 14 hours ago* (last edited 10 hours ago)

Using integer primary keys often creates race conditions when you have multiple database shards, so UUIDs have become the standard. (2 different webservers can create a record in 2 different database that then sync with eacho ther in the background). Using UUIDs for SQLite is less common though as SQLite is mostly used for small or local applications, but developers are used to UUIDs now and even consider them the standard for primary keys now so you do see them in SQLite databases. (Oh and there's some SQLite compatible sharding servers too)

[-] calcopiritus@lemmy.world 2 points 13 hours ago

Can't you just reserve X bits of the primary key to store a shard ID?

[-] 8uurg@lemmy.world 1 points 25 minutes ago

You would be inventing some style of UUID. Include a timestamp in front, so that it is sortable and you have Snowflake.

[-] exussum@lemmy.world 2 points 12 hours ago

If you are owning every little part of the design in every nuance, sure. But how do you configure this in mysqll, postgres, etc etc. does your favorite framework support this easily.

[-] ghodawalaaman@programming.dev 1 points 13 hours ago

wow, I didn't know we can have multiple databases for a single app/website. I assumed it wasn't possible when I learned about k8s and the teacher said there will always be one database while you can replicate your frontend/backend pods

[-] x00z@lemmy.world 1 points 10 hours ago

Both setups are possible.

[-] bitfucker@programming.dev 9 points 14 hours ago

Lemmy sure loves swallowing my reply. To answer your question shortly is an offline first app where the user can add records and the relation during offline and then sync it later after connection is re-established.

[-] eager_eagle@lemmy.world 6 points 14 hours ago

the irony of this comment 😅

[-] ghodawalaaman@programming.dev 1 points 13 hours ago

um, I am not sure if I understood this.

Let's say I want to create a record with my username and password. I will create it offline like saving it in a Json or plain text file. now when I get an internet connection back I will just send that username and password to the database. here the user isnt sending the Id so it shouldn't matter. but if the user is sending the Id then yeah I can see how it could become a problem. eg, two user can be sending the same Id 500 and will lead to race condition as someone else mentioned here.

is it correct?

[-] vrek@programming.dev 2 points 11 hours ago

Yeah if your only storing username and passwords and hoping no one uses the same username. Now consider I'm running tests on a piece of hardware and storing results in the database. I run 45 tests per unit so I can't use serial number as id, I want a way to get all results for a single unit and I have 5 testers since I'm high volume but each test takes 30 seconds.

Tester 1 and tester 4 might get same pk if offline, random IDs for each record won't work since I can't combine everything for 1 unit. This is more why you use uuids for each test

[-] ghodawalaaman@programming.dev 1 points 2 hours ago

go it Thanks :D

[-] vrek@programming.dev 1 points 2 hours ago

As always, best choice is it's depends on situation

[-] lankydryness@lemmy.world 3 points 12 hours ago

lots of people, I use them in certain applications. Not sure I’ve ever had a use case where I needed to memorize the PK of my data, but I suppose if you needed that, then a simply INT might be the choice.

As for sorting/creation related to each other, you can use UUIDv7. The first group of bits is time since epoch. So they naturally sort based on time created. Handy!

[-] eager_eagle@lemmy.world 5 points 15 hours ago

In most cases it's more useful they're not predictable, and I'm definitely not remembering private keys myself, so what's the point. You can have preservation of creation order with UUID v6 and v7.

[-] fizzbang@lemmy.world 4 points 14 hours ago

Distributed systems where the identity isn’t provided by the DBMS need UUIDs. I don’t really get why you’d use uuids in sql, except in the case mentioned where the client is bringing its own ids

this post was submitted on 06 Jun 2026

35 points (97.3% liked)

Programming

27173 readers

315 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 3 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

UlrikHD@programming.dev

bugsmith@programming.dev

Spyro@programming.dev