Why the design can be fast
SQLite reads and writes a local database file through a mature embedded engine. For small queries, removing the network hop can matter more than changing query syntax or adding caches. A monolith also avoids distributed coordination between many services. One codebase can execute a business transaction without network calls across several independently deployed components. WAL mode allows readers to continue while a writer commits. SQLite still has one writer at a time, but many products do not have enough concurrent write pressure for that to become the bottleneck.The basic architecture
What Litestream provides
Litestream watches SQLite’s write-ahead log and copies changes to a remote replica such as S3. After a host failure, you restore the database from that replica onto a replacement volume and restart the application. It provides a recovery path and a potentially small recovery point. It does not provide:- Synchronous zero-data-loss replication by default
- Automatic leader election
- Transparent failover to another writer
- Multi-region active-active writes
- Protection from application-level corruption or accidental deletion without retention
Where it fits
This design works well for:- SaaS control planes with moderate write volume
- Internal tools
- Content and workflow systems dominated by reads
- Early products where one larger machine has ample capacity
- Teams that value simple backup and deployment procedures
- Workloads that can tolerate a short recovery process after host failure
Where it does not fit
Choose a client-server database when you need:- Sustained concurrent writers
- Independent horizontal scaling across many application hosts
- Managed automatic failover with a strict recovery-time objective
- Synchronous replicas for a near-zero recovery-point objective
- Heavy analytical queries alongside transactional traffic
- Database access from many separately deployed services
Operate the simple system seriously
A simple architecture still needs production discipline:- Put the database on a durable, encrypted volume.
- Enable WAL mode and configure busy timeouts deliberately.
- Keep transactions short.
- Monitor disk space, write latency, lock contention, and replication lag.
- Replicate to a separate failure domain.
- Keep point-in-time retention appropriate to the data.
- Automate host replacement and database restore.
- Practice both rollback and disaster recovery.
- Take the application offline or coordinate writes during migration when required.
Simplicity is a capacity choice
Do not choose SQLite because it avoids thinking about data. Choose it when one writer, one durable host, and a tested restore process satisfy the product’s reliability and growth requirements. A vertically scaled monolith can remain the right system for a long time. Move to a distributed database when measurements and recovery objectives require it, not because the architecture diagram looks more advanced with one.Frequently asked questions
Is SQLite suitable for production applications?
Is SQLite suitable for production applications?
SQLite is suitable for production when one host, one writer at a time, local durable storage, and a tested recovery process meet the workload requirements. It fits many control planes, internal tools, content systems, and read-heavy applications with moderate write concurrency.
What does Litestream do for SQLite?
What does Litestream do for SQLite?
Litestream continuously copies SQLite write-ahead log changes to remote storage and supports database restoration after host or volume failure. Litestream improves backup recovery, but it does not provide synchronous replication, automatic leader election, transparent failover, or active-active writes.
When should I move from SQLite to PostgreSQL?
When should I move from SQLite to PostgreSQL?
Move when measured needs include sustained concurrent writers, many independent application hosts, strict automatic failover, synchronous replication, heavy analytical workload, or database access from separately deployed services. Do not migrate solely because the product reached an arbitrary user count.