For most of computing history, SQLite occupied an awkward middle ground. Developers knew it as the database in mobile apps, the thing that powers Firefox's bookmarks, and the embedded database you'd use when you needed "just a database" without the overhead of a server. The conventional wisdom was clear: SQLite is fine for development and small tools, but when you're serious, you use Postgres or MySQL.
That conventional wisdom is being quietly dismantled. Not with fanfare, but through a series of architectural decisions, new tooling, and real-world deployments that are changing what "serious" use of SQLite looks like.
What Actually Changed
SQLite the database hasn't changed dramatically—it's always been technically impressive. What changed is the ecosystem around it, and the rise of workloads where SQLite's architectural properties are actually advantages rather than limitations.
The biggest shift: Cloudflare D1. When Cloudflare shipped D1—their serverless database built on SQLite—and deployed it across their global network, it validated something important. SQLite's single-file, embedded architecture turns out to map extremely well to edge computing, where you want data to live close to compute with no network hop between the two. Each edge location can have its own SQLite database, queries are local and fast, and the replication problem (keeping those databases in sync) is an engineering challenge that Cloudflare and others are actively solving.
Turso takes a similar approach, offering SQLite at the edge with a replication protocol that handles multi-region distribution. The result: SQLite semantics and simplicity, with global reach.
The WAL Mode Revelation
Many developers who dismissed SQLite for production work had encountered it in its default journal mode, where writes block reads and the concurrency story was genuinely limiting. What fewer people knew is that SQLite's WAL (Write-Ahead Logging) mode changes this significantly. With WAL enabled, readers don't block writers and writers don't block readers. Concurrent reads happen in parallel. For read-heavy web applications—which is most web applications—this removes the primary objection.
PRAGMA journal_mode=WAL;That single pragma makes SQLite dramatically more suitable for production web workloads. A lot of the "SQLite can't handle production" wisdom predates or ignores WAL mode.
Litestream and the Backup Problem
The other main objection to SQLite in production was operational: what do you do about backups and disaster recovery when your entire database is a file on disk? Litestream answered this. It's a standalone tool that continuously streams SQLite changes to object storage (S3, R2, etc.) in real-time. Recovery is a matter of replaying the stream from your backup store.
The operational simplicity this enables is underappreciated. Instead of running a database server, managing connections, configuring replication, and dealing with the operational overhead of PostgreSQL or MySQL, you run your application with an embedded SQLite file and Litestream handling durability in the background. For small-to-medium applications, this is genuinely simpler.
Performance That Surprises People
SQLite eliminates network latency between application and database because they run in the same process. For applications where the database is the bottleneck, removing that network hop—even on a local network—can improve query throughput dramatically. Benchmarks showing SQLite outperforming Postgres for read-heavy workloads on single machines aren't cherry-picked edge cases; they reflect a real architectural advantage for co-located application and data.
The limitation is what it's always been: SQLite is a single-writer database. You can't scale writes across multiple machines the way you can with a distributed database. But most applications are read-heavy, and for those workloads, the co-location advantage is real.
Who's Actually Using It in Production
Beyond Cloudflare's edge infrastructure: Expensify runs their entire accounting system on SQLite. Many successful indie developers have written about running SQLite at significant scale for SaaS products without issues. The Rails community has been particularly enthusiastic, with Solid Queue, Solid Cache, and Solid Cable all built around SQLite, pushing it as the default for Rails apps that don't need distributed scale.
The Honest Assessment
SQLite isn't the right tool for every database workload in 2026, and anyone telling you otherwise is overselling it. If you need multi-writer distributed scale, geographic replication with strong consistency, or complex concurrent write patterns, you need a client-server database. PostgreSQL remains the right default for serious applications with those needs.
But the mental model of "SQLite is for toys" was always somewhat wrong, and it's increasingly wrong now. For embedded use cases, edge computing, single-server deployments, and applications where read performance and operational simplicity matter more than distributed writes, SQLite deserves serious consideration. The tools around it have matured to the point where the operational objections are largely answered. What's left is mostly choosing the right tool for the actual workload rather than defaulting to convention.