A SaaS boilerplate that runs SQLite in production — on purpose
Not "SQLite for dev, Postgres for prod". The database is a file on the same disk, in WAL mode, backed up by cron — and for a single-box SaaS that is a feature, not a compromise.
The SQLite renaissance is not a meme
Expensify scaled its backend on SQLite. Tailscale has written about running production services on SQLite with Litestream. Pieter Levels ships profitable products on it. The pattern they proved is simple: for an app that lives on one box, an in-process database has no network hop to pay on every query, backs up as a single file, and cannot be misconfigured — there is no server to configure. Simple Stack commits to that pattern: SQLite is the production database, not a dev convenience you are expected to swap out before launch.
What production SQLite looks like here
Write-ahead logging lets readers work alongside the writer — the setting that makes SQLite a real web database.
The whole database is one file, so backup is a scheduled copy — and restore is copying it back.
No connection strings, no pooler, no managed instance. The database exists the moment PHP does.
SQLite on one box vs a managed Postgres
| SQLite (Simple Stack) | Managed Postgres | |
|---|---|---|
| Database server to run and pay for | × | |
| Query latency | In-process, no network hop | Network round-trip |
| Backup | cron copies one file | Managed snapshots |
| Concurrent readers under write (WAL) | ||
| Dev and prod databases identical | ~ | |
| Multi-machine write scaling | × |
Common questions
SQLite does not scale to many writer machines — true and irrelevant on a single box, where WAL mode serves real paying traffic comfortably. The full argument is on Ship a SaaS on a $5 VPS.
Every live demo is reading from a SQLite file right now.
Click through them, then ship your own — no database server required.