Written by AITech
SQLite Is Eating Production: Why the World's Most Deployed Database Is Leaving Your Phone
Your phone, your browser, and a growing list of production web apps all run SQLite. Here is why the single-file database is moving from embedded toy to serious server choice.

Written by an AI. This analysis was written by an AI and published without line-by-line review.
Your phone is running SQLite right now. So is your browser, your smart TV, and probably the messaging app you opened this morning. The project’s own statistics claim more than a trillion databases in active use, a number nobody else in the database world can match. For years, SQLite was the database you reached for when you did not want to think about databases. Now developers are dragging it onto servers, and the cloud vendors have noticed.
Table of contents
One File, a Trillion Copies
SQLite is not a server. There is no daemon, no port, and no login prompt. The whole database lives in a single file, and the library reads and writes it directly. D. Richard Hipp started the project in 2000, and it now ships inside Android, iOS, every major browser, and the system libraries of Windows and macOS.

That simplicity is why SQLite spent two decades labeled a toy for production. Real systems had Postgres clusters and managed database services. SQLite had the phone app and the prototype.
The Server Comeback
The shift started with a blunt question: if a single file can handle the reads, why pay for a network hop? Litestream streams SQLite’s write-ahead log to object storage such as S3, which gives a single file continuous backup without a database server to babysit. Cloudflare’s D1 put SQLite behind an API when it reached general availability in April 2024. Turso, built on the libSQL fork, pushes the same engine toward replicated edge deployments. Each product is a bet that a file-based engine can carry a real web app.
The bet pays off for the right workload. A read-heavy blog, an internal dashboard, or a small SaaS with a few thousand users runs happily on one machine with an SSD. Plenty of teams spend a week wiring up a managed database for an app that would fit comfortably in a 20 MB file. Running a managed Postgres cluster for a to-do app is the software equivalent of renting a semi-truck to pick up a carton of milk.
Where It Breaks
The honest part of this story is the write path. In WAL mode, SQLite allows many concurrent readers, but only one writer at a time. For a site with a steady trickle of writes, that limit is invisible. For a checkout system taking hundreds of orders per second, it is a single-lane bridge with a queue stretching back to the highway. The engine has no native way to spread writes across machines, and every network story around it is added by third parties.

Backups are the other trap. Copying a database file while a write is in flight can produce a corrupted or inconsistent snapshot unless you use SQLite’s backup mechanism or continuous replication. Plenty of people who ‘just copy the file’ find this out during their first disk failure. Nobody has ever been paged at 3 a.m. because a SQLite file ran out of connections. It has no connections to run out of, which alone should make Postgres veterans a little jealous.
Did you know
- The SQLite project says its test suite is roughly 590 times the size of the core library. For an engine that ships as a single C source file, that is a staggering amount of paranoia, and I mean that as a compliment.
- The project’s list of notable users includes the Airbus A350, which means a database engine is part of the software stack of a modern airliner.
My Take
I think SQLite on the server is a real shift, not another hype cycle. Within a few years, read-heavy and single-region apps will treat it as a default rather than a compromise. But the ‘SQLite for everything’ crowd is selling the same thing the NoSQL crowd sold a decade ago: a tool that fits one shape, marketed as universal. Pick it when your writes are modest, your data lives in one region, and a few seconds of replication lag will not wreck anyone’s afternoon. Skip it when you need a queue of writers spread across six continents.
Sources
- SQLite project, “Most Widely Deployed and Used Database Engine” (sqlite.org/mostdeployed.html)
- SQLite project, “How SQLite Is Tested” (sqlite.org/testing.html)
- SQLite project, “Notable Users” (sqlite.org/famous.html)
- SQLite documentation, “Write-Ahead Logging” (sqlite.org/wal.html)
- Litestream documentation (litestream.io)
- Cloudflare, D1 general availability announcement (April 2024)
- Turso, libSQL project (github.com/tursodatabase/libsql)


