SQLite in production: patterns that have aged well

Actualizado: 2026-05-03

SQLite has been the world’s most deployed database for twenty-five years, but for most of that time it was dismissed as a toy option for servers. That perception has shifted in the last three years thanks to three forces: mature WAL, NVMe disks universal on even cheap VPS plans, and projects like Litestream and libSQL that solved the two classic objections, lack of replication and lack of remote access.

Key takeaways

• WAL mode changes SQLite so profoundly that talking about SQLite-without-WAL and SQLite-with-WAL as the same database is misleading: the concurrency difference is two orders of magnitude on typical web loads.
• Litestream streams the WAL to an S3-compatible object store in near real time, enabling point-in-time restore with at most a few seconds of data loss.
• libSQL, the SQLite fork Turso maintains, adds embedded synchronized replication for geographically distributed architectures.
• SQLite covers most web applications with fewer than a thousand concurrent users and databases under 100 GB.
• Doesn’t apply when the load has intensive concurrent writes, multi-server file access is needed, or advanced Postgres extensions are required.

WAL mode changes everything

The gap between SQLite in the default rollback journal mode and SQLite with WAL enabled is so wide that talking about both as the same database is misleading. Rollback mode serializes writes and reads on a single file lock. WAL mode allows concurrent reads while a write is active and restricts collisions to simultaneous writers. For web apps with a 95 to 5 read-to-write ratio, the performance difference is two orders of magnitude.

Enabling WAL is a single statement at database open time. The WAL file and main file must share a filesystem; trying to put them on different volumes breaks atomicity.

Litestream and replication was the turning point

Until Litestream arrived in 2021, the only decent way to back up a live SQLite database was to stop writes, copy the file, and resume. Litestream solved the problem by streaming the WAL to an object store like S3 in near real time, enabling point-in-time restore with at most a few seconds of data loss.

The most recent evolution is libSQL, the SQLite fork Turso maintains. It added embedded synchronized replication, allowing a primary server database and local replicas on each client or in regional nodes. The stable 1.0 release of Turso Database landed this autumn.

Loads where SQLite is still the best choice

SQLite on server with WAL and Litestream covers without blinking most web applications with fewer than a thousand concurrent users and databases under 100 GB. The most visible success story is sqlite.org itself, which serves its entire site from a SQLite with several million monthly page views.

The second niche is development and testing. Being able to swap Postgres for SQLite in CI cuts test startup time from tens of seconds to under two.

Where SQLite is still a bad idea

• Sustained intensive concurrent write workload: SQLite serializes writers by design. A system with hundreds of write transactions per second will hit a ceiling.
• Multi-process architecture with several application servers accessing the same file: locking over NFS is unreliable and has been the source of corruptions in real projects. Period.
• Needing advanced Postgres features: serious geospatial extensions, production-grade full-text search, or two-phase transactional support.

When it pays off

The question is no longer whether SQLite can sustain a web server, because it can. The question is whether your concrete case fits its strength profile. If your app reads far more than it writes, fits on a single server, doesn’t need synchronous multi-node replication, and you value operational simplicity of a file with no server process, SQLite with WAL and Litestream is probably the lowest total cost option.

The beauty of SQLite in 2025 isn’t that it replaced Postgres, but that it stopped being an eccentric option for a certain range of problems. That range is larger than most people assume.

Conclusion

SQLite with WAL and Litestream can save weeks of infrastructure assembly that adds nothing to a service with 200 monthly active users. Taking it seriously before assuming you need a separate database server is part of practical engineering.