SQLite is not a toy database — and a growing set of production apps is proving it

SQLite is the most widely deployed database engine in existence. It runs inside every Android device, every iPhone, every desktop browser, every Mac, and most Windows systems. There are estimated to be over one trillion SQLite databases in active use. And for most of its history, the implicit rule in web development has been: SQLite is fine for development and testing, but you graduate to Postgres or MySQL before you ship.

That rule is being actively challenged — not as a contrarian take, but by developers running real production systems and reporting real results. The change is partly philosophical and partly technical.

The traditional objection

The standard case against SQLite in production web applications rests on concurrency. SQLite is a file-based database: all reads and writes hit a single file on disk, and while it supports multiple concurrent readers, it only allows one writer at a time. In WAL (Write-Ahead Logging) mode, enabled since 2010, readers and the single writer don't block each other — but you still get one writer. For applications with high write concurrency, this is a hard constraint.

The second objection is operational: if your application runs on multiple servers, they can't share a SQLite file. Distributed databases like Postgres over TCP/IP are designed for this; SQLite is not. This made SQLite essentially non-viable for horizontally scaled web applications.

Both objections are real. Neither is universal.

What changed: the replication ecosystem

In 2021, Ben Johnson released Litestream — an open-source tool that streams SQLite's WAL file to S3-compatible object storage in near real time. The pitch: you get automatic off-site backup with sub-second RPO, without changing your application code or switching to a client-server database. Litestream doesn't solve the single-writer constraint; it solves the disaster recovery and backup problem that made SQLite feel unsafe for production. For many use cases, that's the more pressing concern.

Fly.io took this further with LiteFS, a distributed file system that uses FUSE to intercept SQLite writes and replicate them to replica nodes. LiteFS gives you a primary node that accepts writes and read replicas that follow it — similar to Postgres streaming replication, but for SQLite. Applications that can route writes to the primary and reads to any replica benefit from horizontal read scaling without changing the database engine.

The most ambitious effort is Turso, built on libSQL — a fork of the SQLite codebase that adds a network protocol, multi-tenancy, and edge replication. Turso's pitch is "SQLite at the edge": every user gets a database shard running geographically close to them, eliminating the latency of a central database. The company raised $32 million in a 2023 Series A. libSQL is open-source; Turso's managed service is the commercial product. Cloudflare's D1 database service uses a similar architecture, offering SQLite-compatible storage as a serverless primitive.

The performance argument

For applications where the database lives on the same machine as the application server — which is true for a large percentage of self-hosted and small-to-medium applications — SQLite with WAL mode often benchmarks faster than Postgres or MySQL for read-heavy OLTP workloads. The reason is elimination of network latency: a local SQLite query doesn't traverse a TCP connection. The cost of a network round-trip to a Postgres server, even on localhost, is a few hundred microseconds. At high query volumes, this adds up.

The 2015 COST paper ("Scalability! But at what COST?") made a related point in the context of distributed graph processing: a single machine running well-tuned single-threaded code often outperformed distributed systems like Hadoop for graphs that fit in RAM. The insight generalizes: distributed systems have overhead, and if your data fits on one machine, you may be paying that overhead for no benefit.

SQLite's WAL mode is also extremely well optimized for high read concurrency. Benchmarks from Turso and independent developers consistently show SQLite handling tens of thousands of reads per second on modest hardware, well within the range of most production web applications.

Who's actually doing this

37signals — the company behind Basecamp and Hey — has been the loudest public advocate. DHH's 2023 blog post arguing that SQLite with Litestream is sufficient for most web applications generated significant discussion. 37signals uses a "one database per customer" model for some of its infrastructure, where SQLite's single-file-per-database property becomes an advantage: each customer's data is isolated in its own file, and backups are trivially simple.

Many indie developers and small teams have migrated to SQLite for similar reasons: simpler operational model, no separate database server process to manage, trivial backup (copy the file), and performance that meets their needs. The rise of platforms like Railway and Fly.io, which make it straightforward to run persistent SQLite alongside a web application, has lowered the operational barrier further.

Where it still doesn't make sense

The single-writer constraint is a real ceiling. Applications with sustained high write throughput — analytics ingestion pipelines, high-frequency trading systems, social platforms with millions of simultaneous write operations — genuinely need a database that can spread writes across multiple nodes. SQLite cannot do this natively, and the replication tools built around it don't change the fundamental write model.

Very large datasets also present challenges. SQLite supports databases up to 281 TB in theory, but practical performance on databases over a few hundred gigabytes degrades. Postgres's vacuum, autovacuum, and partitioning features are mature and well-understood at scale; SQLite's equivalent mechanisms are simpler and less battle-tested at large sizes.

The rule of thumb emerging from the community: if your write QPS is under a few thousand per second and your dataset fits comfortably on a single disk, SQLite with WAL is worth evaluating seriously. If you need multi-primary writes, cross-datacenter synchronous replication, or row-level security with complex role hierarchies, Postgres is still the right tool.

What's changed is the framing. SQLite is not a toy. It is a mature, extensively tested database engine with over two decades of production use in contexts far more demanding than most web applications. The question isn't whether SQLite is serious — it's whether the specific constraints of your application fit its model. For a growing number of production systems, they do.