I'm All-In on Server-Side SQLite

Summary

Ben Johnson argues that SQLite should be considered as the core data and persistence layer for many production full-stack applications, rather than being relegated to unit tests in an n-tier architecture. He attributes this case to cheaper, faster hardware and the fact that most successful applications will never approach terabyte-scale data, making distributed database infrastructure excessive for some workloads. Litestream works alongside standard SQLite by taking control of WAL-mode journaling, capturing WAL updates, replicating them to storage such as S3, and handling checkpoints itself. This preserves ordinary SQLite libraries and transactions while providing a path to restore copies and improve resilience to storage failure; upcoming direct database-to-database replication is also mentioned. The resulting model places data in the application process, where the post reports 10–20 microsecond per-query latency, but it remains aimed at single-node applications and has restore, deployment, and replication-guarantee limitations.

Takeaways

1. 1

   SQLite runs inside the application process, with the post reporting per-query latency of 10–20 microseconds— described as a 50–100x improvement over an intra-region Postgres query.

2. 2

   Litestream does not parse queries, proxy transactions, or require a new application library; it uses SQLite's existing journaling and concurrency features through a separate process.

3. 3

   The design targets single-node applications and is unsuitable for ephemeral serverless platforms or rolling deployments; sequential restores can take minutes, and the separate process limits replication guarantees to coarse-grained control.