SQLite is the most deployed database in the world. It runs on every phone, in every browser, and in countless embedded systems. But developers rarely consider it for web applications. That’s changing.

SQLite’s Superpowers

No server. SQLite is a library, not a process. No connection management, no networking, no configuration. Open a file, run queries.

Incredibly fast for reads. With the database file on local disk (or SSD), read queries complete in microseconds. No network round-trip, no connection pool, no parsing overhead from a client-server protocol.

ACID compliant. Full transactions, crash recovery, and durability. SQLite has been battle-tested for decades.

Single file. The entire database — data, schema, indexes — is one file. Backup is a file copy. Migration between environments is a file transfer.

Where SQLite Works for Web Apps

The Litestream project and tools like LiteFS made it viable to run SQLite in production web servers by providing replication and backup:

# Continuous replication to S3
litestream replicate /data/app.db s3://my-bucket/app.db

Combined with edge computing platforms, SQLite is compelling for:

  • Read-heavy workloads. Blogs, documentation sites, product catalogs.
  • Single-region applications. If all your users are in one region, local SQLite is the fastest option.
  • Embedded applications. Desktop apps, mobile apps, CLI tools.
  • Development and testing. Zero setup, instant teardown.

WAL Mode

Write-Ahead Logging (WAL) mode is essential for concurrent access:

PRAGMA journal_mode=WAL;
PRAGMA busy_timeout=5000;
PRAGMA synchronous=NORMAL;

WAL allows multiple readers alongside a single writer. Without WAL, any write locks the entire database.

When SQLite Doesn’t Work

  • Multiple concurrent writers. SQLite serializes writes. If you need high write throughput from multiple sources, use PostgreSQL.
  • Multi-region reads. SQLite is a file. Distributing it across regions requires replication tooling.
  • Large datasets. SQLite handles terabytes, but the operational tooling (monitoring, partitioning) isn’t there.
  • Complex replication needs. Leader-follower, multi-leader — this isn’t SQLite’s domain.

The Practical Choice

The question isn’t “can SQLite handle my workload?” It’s “do I need the complexity of a database server?”

For a significant number of web applications, the answer is no. A single SQLite file with WAL mode, proper indexes, and periodic backups handles more traffic than most applications will ever see.

Start with SQLite. Move to PostgreSQL when (if) you hit its actual limits, not its perceived ones.