SQLite as your only database - a production tuning walkthrough

A field guide argues embedded SQLite can carry a real production workload - if you know the WAL/mmap/VFS knobs. Under the hood, plus the trade-offs it won't fix.

In plain terms. A new engineering post argues that SQLite - the embedded database that lives inside your app - can serve a real production workload if you configure it right. It walks through the pragmas, journaling mode and virtual filesystem layers that turn the toy default into a low-latency server backend.

Context

The post - "SQLite in Production: Optimizing WAL Mode, Concurrency, and VFS Layers for Low-Latency App Servers" (micrologics.org, 29 July 2026) - reads as a practitioner's blueprint. It targets teams who reach for Postgres reflexively and want to ask whether the network hop to the DB was ever the cheap part.

Under the hood

Three levers do most of the work:

WAL mode.PRAGMA journal_mode=WAL; replaces the rollback journal with a separate -wal file. Readers and writers stop blocking each other on the page cache; only writers still serialize. The catch: unattended, the WAL file grows. You need a checkpoint strategy - PRAGMA wal_autocheckpoint, or explicit PASSIVE/FULL/RESTART/TRUNCATE calls from the app.

Contention shape. SQLite is a single-writer engine. The post's baseline: PRAGMA busy_timeout = 5000; for automatic retries, and BEGIN IMMEDIATE; for any transaction that plans to write - avoids the classic upgrade-deadlock when two BEGINs race.

Memory.PRAGMA cache_size = -64000; (64 MB) and PRAGMA mmap_size = 1073741824; (1 GB) turn most reads into pointer arithmetic.

Analysis

What makes the post worth reading isn't the pragmas - those are old news. It's the framing: SQLite's VFS is the extension point that changes the architecture. Litestream (async replication to S3) and LiteFS (FUSE-based distributed layer) turn the local-file assumption into a network-tolerant one without touching your query code. On ephemeral cloud disks, the VFS layer is what you actually design around, not the pragmas.

Trade-offs the post owns

Explicit limits: multi-terabyte datasets, geo-distributed writes, workloads that need real MVCC across many writers. Below those ceilings, the post argues the operational surface is smaller than a managed Postgres - and the p99 latency is a memory-copy, not a socket round-trip.

So what

For teams building an AI-era backend where the "database" is often a per-tenant blob and the hot path is 1-5 ms, the question is no longer why SQLite in production, but which VFS. The post is best read as a checklist you paste next to your main.go - not as a promise that you can retire your cluster.