SQLite serves every query in-process (sub-millisecond, no network) while Postgres stays a continuously-synced read-only mirror. Switching takes three steps: seed → switch → restart.
How far the read-only Postgres mirror is behind right now. The replicator drains every change within seconds; a growing backlog means Postgres is unreachable and your disaster-recovery copy is going stale.
A WAL-safe snapshot of the SQLite file is taken daily and the newest few are kept in
data/backups/. Take one now any time. To restore: stop the app, copy a snapshot over the live db
(remove stale -wal/-shm sidecars), restart.
| Snapshot | Size | Taken |
|---|---|---|
| — | ||
Copies every row from Postgres into the local SQLite file. Re-runnable (recreates the file). Run this before the first switch — and again if you ran on Postgres for a while and want SQLite to catch up. Refused while the app is already serving from SQLite.
The engine is read once at startup, so the choice applies after a restart — restart your process manager (Docker / systemd) in production, or re-run locally. Until then the app keeps serving from the engine it booted with. Switching back is the same flow in reverse; with the mirror on, Postgres is always current — switching back to Postgres loses nothing.