SQLite Is Everywhere, and That’s Not an Accident

By most conventional metrics, SQLite shouldn’t be interesting. It has no server process, no user management, limited write concurrency, and ships as a single C file. It was designed for embedded systems — the kind of constrained environments where spinning up a “real” database is simply not an option.

And yet SQLite is almost certainly the most widely deployed database engine in existence. It runs inside every Android and iOS device, every desktop browser, most desktop applications, and an enormous swath of backend tooling. The question worth asking isn’t why SQLite is popular on phones — that much is obvious. The question is why it keeps expanding into new territory that was never part of the original design.

What Makes It Structurally Appealing

SQLite’s constraints are also its strengths. The entire database lives in a single file. There’s no daemon to configure, no connection pooling to manage, no authentication layer to set up. You open a file, you run SQL, you close it. ACID compliance is built in, and the on-disk format is stable across decades.

For developers, this translates to something genuinely valuable: zero operational surface area. A SQLite-backed application has one dependency fewer than a Postgres-backed one, and that dependency is a library, not a service. In testing pipelines, that difference is enormous — spinning up an isolated in-memory SQLite instance per test is trivial in a way that containerized Postgres simply isn’t.

This is why SQLite became the default choice for application testing even in shops that run Postgres or MySQL in production. The tradeoffs are well understood, and for test isolation, they don’t matter.

The Local-First Shift

The deeper reason SQLite keeps expanding is that the industry’s relationship with “where data lives” is changing. For roughly two decades, the dominant model was client-as-thin-terminal: state lives on the server, the client renders it. That model is fraying.

Offline-capable applications, sync engines, and local-first architectures all require a capable storage layer on the device or at the edge. SQLite is the only embedded database with the right combination of features — real SQL, transactions, decent performance, and universal platform support — to fill that role. Browsers gained access to SQLite via the Origin Private File System API, which lets web applications persist a real SQLite database locally. Edge compute platforms need local state to be useful without round-tripping to a central database, and SQLite fits that constraint naturally.

The broader pattern: as compute moves to the edges — devices, CDN nodes, regional workers — it needs data storage that travels with it. SQLite was built for exactly that model, just applied to different hardware than originally imagined.

What the Ecosystem Built on Top

The limitations of raw SQLite have spawned a productive layer of tooling. Write concurrency is the most cited constraint: SQLite serializes writes at the file level, which makes it a poor fit for multi-process, high-write-concurrency server workloads. WAL mode (Write-Ahead Logging) improves concurrent read performance significantly, but the fundamental single-writer model remains.

Projects like Litestream address the operational gap by streaming SQLite changes to object storage, giving embedded databases replication and point-in-time recovery without a replication protocol. Turso, built on a fork of SQLite called libSQL, adds a server layer and multi-tenancy to enable database-per-user architectures at scale. Cloudflare’s D1 is a managed SQLite offering designed specifically for edge workers. These aren’t workarounds for SQLite’s limitations so much as specializations for contexts where those limitations don’t apply.

The Broader Lesson

SQLite’s trajectory illustrates something the industry relearns periodically: the most durable infrastructure is the kind that does exactly one thing with extreme reliability and gets out of the way. SQLite doesn’t try to be a distributed system. It doesn’t have a cloud offering or a managed tier baked in. It is a well-specified file format with a SQL interface, and that simplicity is precisely why other things get built on top of it.

The databases that compete with SQLite for new workloads will need to match it on the things that actually matter in embedded and edge contexts: zero-config startup, a stable on-disk format, and predictable behavior under constraint. That’s a harder target than it looks.