SQLite is enough until concurrent writes prove otherwise

sqlite is enough until concurrent writes prove otherwise. a defense.

SQLite is a file on disk. That's it. That is the whole architecture. There is no server process. No connection pooling. No pg_hba.conf you will misread at 11pm. No Docker container running postgres that is using 300MB of RAM to hold twelve rows of data for your blog. Just a file. Your app opens it. The data is there.

It is also, as of right now, the most widely deployed database engine in history. It lives in your phone. Your browser. Your desktop apps. Every Electron app you have cursed at has an SQLite database somewhere. Billions of instances. It is fine. It has always been fine. You are the one who wasn't fine.

// the uncomfortable reality about 95% of businesses

Let's do the math that nobody wants to do. The average SaaS, indie app, internal tool, content site, or startup at the idea-to-Series-A stage has:

METRIC	WHAT FOUNDERS IMAGINE	ACTUAL REALITY	SQLITE HANDLES IT?
Daily active users	100,000+ (conservatively)	120. 40 are bots.	Yes. Effortlessly.
Database writes/sec	Millions, probably	~3. Maybe 10 on Mondays.	Yes. It's yawning.
Database size	Petabytes. Obviously.	14MB after 2 years.	Yes. Max is 281TB.
Query complexity	Distributed joins across 6 services	SELECT * WHERE user_id = ?	Yes. Child's play.
Concurrent users	Viral moment incoming, surely	4 (you, cofounder, 2 testers)	Yes. It barely notices.
Infrastructure team	SRE team of 12	You. At midnight.	Yes. Nothing to manage.

This is not a knock on ambition. It's a knock on premature infrastructure complexity that costs time, money, and sleep when you could just be shipping. The database doesn't need to be Postgres before the product needs to be Postgres. When that day comes - and it might, genuinely, come - migrating from SQLite to Postgres is documented, tooled, and survivable. Migrating away from an over-engineered mess of microservices is a years-long grief process.

// wal mode: the thing that fixes the one real problem

The one legitimate complaint about SQLite is write concurrency. The default journal mode uses a writer lock that blocks all readers. This is real. This is annoying. This was solved in 2010.

WAL - Write-Ahead Logging - is a mode you enable with one line. One. When WAL is on, writers do not block readers and readers do not block writers. Multiple concurrent reads happen simultaneously. A write queues behind the current write, not behind every read. For 95% of workloads, this is completely sufficient and you never need to think about it again.

What WAL does not fix is extremely high write concurrency - think thousands of simultaneous writes per second from dozens of processes. At that point, yeah, you want Postgres. But if you are at that point, you already know you are at that point. You have the traffic numbers. You have the metrics. You have engineers. This post is not for you. This post is for the person Dockering up a Postgres container to store 400 rows of blog posts.

// the genius move: sharding by file

Here is where SQLite gets interesting in a way that nobody talks about enough. When you hit the limits of a single database - whether write throughput, or just wanting to isolate tenants, or managing data lifecycle - you can shard by creating multiple SQLite files.

This is not a compromise. This is a genuinely powerful pattern used by serious production systems. Expensify ran SQLite at scale for years. Notion used it. Cloudflare's D1 is distributed SQLite. Turso is literally just SQLite with replication bolted on and VCs are calling it revolutionary.

// the actual limits. real ones. for honesty.

This is a blog post that loves SQLite, not one that lies about it. Here are the actual cases where you should use something else:

SITUATION	USE INSTEAD	WHY
High concurrent writes from many processes/servers	Postgres	SQLite is single-writer. If you have 10 app servers all writing simultaneously, WAL won't save you.
Multiple application servers reading/writing the same file	Postgres or LiteFS/Turso	SQLite lives on one machine. You can't mount the same file over NFS under write load and expect happiness.
+10M transactions/second	Postgres, Cassandra, whatever	At that point you have very specific needs and a very specific budget and this post is not for you.
Complex replication requirements	LiteFS, Turso, or Postgres	SQLite doesn't replicate natively. Tooling exists but adds complexity.
Your team knows Postgres deeply	Use Postgres then	Familiarity has value. Use what your team can operate at 3am. This post is about not defaulting to complexity, not about dogma.

None of these limits apply to a side project, a small SaaS, an internal tool, a personal blog, a developer portfolio, or literally anything an indie developer is building right now at any stage before meaningful traction. The limit you will hit first is not the database. It's finding users.

// the verdict. same as it ever was.

SQLite is not a toy database. It is not a "development only" database. It is not a database you graduate from like it's training wheels. It is a legitimate, battle-tested, production-grade database engine that happens to be a file, which makes it simpler to operate than anything with a server process, a config file, and a port number.

Enable WAL. Set a busy timeout. Keep your database local to the app process. Back it up with cp or sqlite3 mydb.db ".backup backup.db". Shard by file if you need scale. Migrate to Postgres the day your metrics actually demand it, not the day you imagine they might.

---

// filed under: obvious in retrospect · written on a machine running SQLite right now · no Postgres containers were harmed in the production of this post