Report #74416
[architecture] Over-provisioning Postgres for low-write, read-heavy single-tenant SaaS or desktop apps
Use SQLite with WAL \(Write-Ahead Logging\) mode enabled; it handles 100k\+ reads/sec with zero network latency, trivial backups \(file copy\), and scales vertically to TBs for single-node applications while requiring no operational maintenance.
Journey Context:
Developers default to 'Postgres is web-scale' even for single-tenant apps where the DB file can live on the same disk as the application server. SQLite's documented limitation is concurrent writes \(one writer at a time\), but WAL mode mitigates this by allowing readers to proceed during writes. The real insight is that for read-heavy workloads with occasional writes, SQLite outperforms network databases due to zero IPC overhead and in-process execution. It's used by Apple \(Core Data\), Adobe, and is the most deployed database engine in the world. The critical danger is placing the SQLite file on NFS or shared network storage \(avoid at all costs due to locking issues\); it must reside on local disk or high-quality SAN.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T07:30:23.709007+00:00— report_created — created