December 20, 2025
One thread to rule them all?
More databases should be single-threaded
One-at-a-time databases? The internet is yelling
TLDR: A viral post claims databases should handle changes one at a time and be split into many small pieces to avoid messy errors. The community erupted: some say it simplifies life (hello, DynamoDB), while others call it naïve or painful in practice—sparking a big simplicity vs. reality showdown.
A bold tweet from Konsti Wohlwend lit up tech Twitter: make databases process changes one at a time and split data into lots of small chunks. Translation: fewer moving parts, fewer “oops” moments. He argues the usual database features—locks, retries, and scary acronyms—cause chaos. Simpler is safer, he says. The crowd? Oh, they had thoughts.
Critics swarmed first. One developer snapped, “Wow, that’s a dumb take,” pointing to ACID—a set of rules that keep data safe so many people can use it at once. Another warned the “simplicity” just moves the mess from the database to your app: now devs must pick how to split data, re-split it later, and somehow keep results consistent. A third lamented, “We’re doing this in production and it’s terrible.” Ouch. Meanwhile, an ex-AWS voice dropped a curveball: this sounds a lot like DynamoDB, which powers tons of Amazon services—so maybe the hot take isn’t that wild. Others joked it’s the “single checkout line on Black Friday” of databases and resurrected the classic meme: “just use SQLite bro.”
Under the memes, the split is real: minimalism vs. messy reality. Fans want fewer foot-guns. Skeptics say you’re just shoving the hard problems into the code—and future you will be the one screaming.
Key Points
- •The author argues most transactional databases should be single-threaded and aggressively sharded.
- •Postgres isolation levels (READ COMMITTED, REPEATABLE READ, SERIALIZABLE) are described with their behaviors and trade-offs.
- •Multi-threaded, lock-based concurrency leads to deadlocks, retries, race conditions, and high lock contention under load.
- •Read-only transactions can use SERIALIZABLE READ ONLY DEFERRABLE to avoid write conflicts.
- •A single-writer model, exemplified by SQLite, ensures perfect ordering but is limited by single-write throughput; sharding is proposed to scale.