SQLite in Production: Optimizing WAL Mode, Concurrency, and VFS Layers(micrologics.org)
246 points by ankitg12 1 day ago | 76 comments
tl;dr: SQLite can handle production web workloads on modern NVMe hardware if you tune it beyond defaults: enable WAL mode with `synchronous=NORMAL`, set a `busy_timeout`, use `BEGIN IMMEDIATE` for write transactions to avoid deadlocks, and increase `cache_size` and `mmap_size` to keep the working set in memory. For durability in ephemeral cloud environments, pair it with VFS-based replication tools like Litestream or LiteFS. It's a strong fit for read-heavy apps under a few hundred GB, but PostgreSQL still wins for distributed multi-region writes or terabyte-scale datasets.
HN Discussion:
  • Article is AI-generated which undermines its credibility and value
  • The synchronous=NORMAL recommendation glosses over real durability tradeoffs and transaction loss risk
  • busy_timeout + BEGIN IMMEDIATE is insufficient; application-level single writer is better for handling contention
  • ~Replication tools like Litestream/LiteFS add complexity that negates SQLite's simplicity advantage over Postgres
  • Practical operational concerns like GUI tooling and migrations are underaddressed in these SQLite-in-prod pieces