SQLite Is Having a Moment in Production — and It's Earned It

SQLite has an image problem. It ships in every iOS and Android device, every browser, and every Python installation. It's the database embedded in WhatsApp's message storage, Firefox's history, and most desktop applications you use daily. Despite this ubiquity, developers reaching for a database for their web application almost universally skip it in favor of PostgreSQL, MySQL, or a managed cloud database — because SQLite is «for embedded use only» and «doesn't scale» and «can't handle concurrent writes.»

These objections are partially true, partially outdated, and partially missing the point. The ecosystem that has grown up around SQLite in the last two years has addressed enough of the real limitations that the conversation has genuinely shifted.

What SQLite Actually Is

SQLite is a serverless, file-based relational database. The entire database lives in a single .db file. There's no daemon to run, no network socket to configure, no connection string to manage — your application opens the file and queries it directly. This architectural simplicity is both its greatest strength and the source of the traditional objections.

The «can't handle concurrent writes» objection is real but widely misunderstood. SQLite uses write-ahead logging (WAL mode), which allows multiple concurrent readers with a single writer. For most web applications — particularly read-heavy ones — this is not a meaningful constraint. The bottleneck in most applications is not database write throughput; it's application logic, network round-trips, and query design. An application handling thousands of requests per second can run fine on SQLite if the write-to-read ratio is reasonable.

The «doesn't scale» objection is true in the horizontal sense: you can't have multiple machines writing to the same SQLite database simultaneously. But you can have one powerful machine running SQLite and serving extraordinary throughput — Expensify notoriously ran much of their infrastructure on SQLite for years.

The Infrastructure Revolution

What's changed in 2024-2026 is the emergence of infrastructure purpose-built to extend SQLite beyond its single-node limitation while preserving its simplicity.

Turso is the most ambitious. Built on libSQL — a fork of SQLite maintained by the Turso team — it provides a distributed SQLite service where you can replicate your database to multiple edge locations. You write to a primary and reads are served from the nearest replica. The libSQL fork adds extensions including vector search and JSON improvements, and the HTTP-based API means you can query it from any language without SQLite bindings. Turso's free tier is generous, and their pricing is based on rows read rather than compute time, which suits the read-heavy patterns where SQLite excels.

Cloudflare D1 takes a different approach. It's SQLite at the edge — your database is distributed across Cloudflare's network and accessed via their Worker runtime. D1 launched publicly in 2023 and has matured significantly. It handles automatic replication and handles the write serialization problem by routing all writes through a primary region. For applications deployed on Cloudflare Workers, D1 removes all the friction of running a database: there's no connection pooling to configure, no database server to provision, and queries have very low latency because they run in the same network edge as your code.

Litestream takes the simplest possible approach: continuous replication of a SQLite file to S3-compatible object storage. You run your application with SQLite on a single server, and Litestream streams every write to S3 in near-real-time. If the server dies, you restore from S3 and you're back in minutes. It's not distributed — it doesn't help with reads — but it solves the durability objection at essentially zero cost. Many small-to-medium applications can operate perfectly well with a single well-provisioned server and Litestream for disaster recovery.

LiteFS from Fly.io takes Litestream's concept further: it's a FUSE filesystem that provides distributed SQLite with primary election and replica propagation. Applications think they're writing to a local file; LiteFS handles the consistency layer.

When SQLite Beats Postgres

For certain workloads, SQLite is not just competitive — it's the better choice.

Applications where each user's data is isolated (think: personal note-taking apps, per-tenant SaaS with strict data isolation, or mobile apps that sync to a server) are SQLite's home turf. Each user gets their own database file; there's no connection pooling problem because each user is their own database; schema migrations can be applied per-tenant without affecting others.

Edge computing is another strong fit. Running Postgres at the network edge is expensive and operationally complex. Running SQLite in a Cloudflare Worker or a small edge node is trivial. For use cases that need low-latency reads with modest write volumes — session state, feature flags, user preferences — D1 or Turso at the edge beats a centralized Postgres with milliseconds of added latency.

Development experience is an underrated advantage. A SQLite database is a file. You can copy it, email it, open it in DB Browser for SQLite, version control schema migrations against it, and run the exact same database in your test suite as in production. The operational complexity of running a Postgres server in development — Docker containers, connection strings, password management — doesn't exist with SQLite.

The Real Limitations

None of this means SQLite is appropriate everywhere. High write throughput — applications generating thousands of writes per second from multiple sources — is genuinely not SQLite's strength. Heavy analytical workloads with complex aggregations over large datasets run better on databases with columnar storage engines. Applications requiring database-level features like row-level security, logical replication for event sourcing, or advanced PostGIS spatial operations need Postgres.

The write serialization in distributed SQLite (Turso, D1) adds latency that doesn't exist in a co-located Postgres with connection pooling. For globally distributed applications with write-heavy workloads, this tradeoff may not be acceptable.

The Takeaway

SQLite in 2026 is not a replacement for Postgres in all cases — and nobody serious is arguing it is. The argument is that the automatic default of «use Postgres» for every new application is worth interrogating. For read-heavy workloads, per-user databases, edge deployments, and applications prioritizing operational simplicity, SQLite plus the modern infrastructure around it is now a genuinely excellent choice. The «not for production» label belongs on a different era's SQLite, not this one.