Why SQLite Is the Most Underrated Production Database

SQLite has a reputation problem. Developers hear “SQLite” and think “local dev database,” “test fixture,” or “mobile app storage.” They don’t think “production web application.” They should.

SQLite is the most deployed database in the world - more deployments than all other databases combined. It runs in every iOS and Android app, every browser, every Electron app. It’s the storage engine for WhatsApp messages, Firefox history, and your local VS Code extensions. And increasingly, it’s the production database for web applications at meaningful scale.

Why SQLite Gets Dismissed (Incorrectly)

The conventional wisdom is that SQLite doesn’t support concurrent writes, isn’t suitable for client-server architectures, and can’t handle the load of a production application.

The first claim was more true in 2015 than it is in 2026. SQLite in WAL (Write-Ahead Logging) mode supports concurrent reads with one writer. Reads and writes can overlap. For most web applications - which are read-heavy - this is not the bottleneck people think it is.

The “no client-server” concern is about deployment, not capability. SQLite is embedded - it runs in the same process as your application and reads from a local file. This is actually an advantage in simplicity: no network round trip to a database server, no connection pool management, no authentication configuration.

The load concern is about measurement. SQLite has benchmarked at 35,000 reads per second and 100,000+ reads per second with in-memory mode on modern hardware. Many web applications never come close to these numbers.

What Changed: Litestream, LiteFS, and Turso

Three developments made SQLite a viable production option for web applications:

Litestream (2021): Continuous replication of SQLite to S3, GCS, or SFTP. Your database file is replicated to object storage in near-real-time. If your server dies, you restore from S3 in under a minute. This solved the “what happens if the server crashes” objection.

LiteFS (2022): A FUSE filesystem that provides distributed access to SQLite across multiple nodes, with primary election and automatic failover. You can run SQLite on multiple machines with a consistent view of the data. This solved the “single server” objection for applications that need HA.

Turso (2023-2026): Managed SQLite at the edge. Turso runs SQLite at Cloudflare’s edge network, with one primary and automatic replication to read replicas close to your users. Costs start at $0 for development and scale to significant usage before hitting Postgres-equivalent pricing.

With Turso, you get SQLite latency (microseconds for reads because the database is on the same machine as your Cloudflare Worker), global read performance, and the operational simplicity of a managed service.

Concrete Performance Comparison

For a typical read-heavy web application:

For read-latency, SQLite has a structural advantage: there’s no network hop. Your application reads directly from the file. Postgres requires a network round trip even on the same machine.

Who Is Actually Using SQLite in Production

Notable production SQLite deployments:

• Expensify: Their primary production database is SQLite, serving millions of expense reports. They wrote a blog post in 2022 explaining how they scaled to millions of users with SQLite.

• Fly.io: SQLite is a first-class option on Fly.io’s platform, with LiteFS for replication. Many applications deployed on Fly use SQLite.

• Cloudflare D1: Cloudflare’s database offering is SQLite. D1 is specifically designed for Cloudflare Workers - the same edge SQLite model as Turso.

• Countless small/medium applications: The “boring” truth is that 90% of web applications don’t have the concurrency requirements that require Postgres. SQLite is sufficient and simpler.

The Stack That Makes SQLite Shine

SQLite’s sweet spot in 2026:

• Cloudflare Workers + D1: Run your application and database at the same edge location. Zero-latency database reads. Free tier includes 5 million D1 reads/day.

• Fly.io + LiteFS: Deploy your application with SQLite, replicate with LiteFS to multiple regions. Automatic failover.

• Single-server applications + Litestream: One server, SQLite for the database, Litestream replicating to S3. Simple and reliable for applications that don’t need horizontal write scaling.

• Bun/Hono/Elysium + SQLite: The newer JavaScript runtimes (Bun especially) have exceptional built-in SQLite support. Bun’s bun:sqlite module is very fast.

When Not to Use SQLite

SQLite is not the right choice when:

• High concurrent writes: If you have multiple application servers all writing heavily, SQLite’s single-writer model creates contention. Postgres with connection pooling is better.

• Large datasets with complex joins: SQLite handles gigabytes of data fine, but for terabyte-scale analytics, a columnar database wins.

• Existing Postgres-specific features: If you’re using Postgres extensions (pgvector, PostGIS, TimescaleDB), those aren’t available in SQLite.

• Teams that need Postgres operators: SQLite’s operational model is different. Teams that know Postgres well and don’t want to learn a different mental model for backups, migrations, and performance tuning should stay on Postgres.

The Migration Question

If you’re starting a new application, SQLite is worth serious consideration if your writes are relatively light. The Turso + Drizzle ORM combination is excellent for TypeScript applications.

If you’re on Postgres and considering moving: don’t. The migration cost is high and Postgres is serving you fine. The SQLite story is for new applications and specific use cases, not a “you should switch everything” argument.

Bottom Line

SQLite is a legitimate production database for the majority of web applications that are read-heavy and have modest write requirements. Litestream, LiteFS, Turso, and Cloudflare D1 have solved the operational limitations that kept it out of production previously. The combination of zero-latency reads (no network hop), zero-cost development, and surprising scalability makes SQLite the right default for new applications until you have a specific reason to need Postgres. The most underrated database in web development is the one already on every device your users own.