benbjohnson/litestream

Litestream is worth a look if you run SQLite as the real database behind a small service and your current backup plan is a cron job that copies the file. It is a disaster-recovery tool, not a replication cluster, and the README labels the project beta.

The problem

You have a single SQLite database serving an app, and you want to be able to recover it after a bad write, a deleted file or a lost disk. Copying the database file on a schedule is the usual approach, but the copy is a point-in-time snapshot and may miss recent writes. Litestream changes that step: it runs as a background process, watches the database's write-ahead log and continuously ships incremental changes to another file or to S3. The result is a replica you can restore from, instead of a single snapshot copied now and then.

What's different

Litestream reads and writes the database only through the SQLite API, and the README says it will not corrupt your database. The mechanism is a WAL-based incremental stream: rather than copying pages, it replicates changes as they happen, so the amount transferred tracks the size of the changes rather than the full database. Restoring is a separate step, not part of the replication loop, so the replica is a backup target rather than a live query endpoint.

The trade-off is that Litestream is closer to continuous backup than to a distributed database. The README describes it as standalone disaster recovery, not a read-replica setup: you get a copy to restore from, not a second node that serves reads. It also modifies the source schema: on first use it creates an internal _litestream_lock table in the source database, which shows up in restored copies too. That means a Litestream-managed database will not stay byte-identical to its pre-Litestream state, and you should not drop that table while Litestream is running. The project is marked beta, so treat the rest of the operational story (monitoring, restore drills, credential handling) as something you own.

Who should try it

Good fit: a small app whose entire persistent state is one SQLite file, where losing the file would be serious and a warm standby is more than you need. You want a cheap, continuous copy into object storage without adding a database server.

Poor fit: teams that need synchronous replication, multiple writers, or read scaling across nodes. A 2022 HN thread tracking the move of live replication to LiteFS illustrates that LiteFS is where the project has aimed the read-replica story; Litestream itself is described in its README as disaster recovery thread. If your workload needs a replicated cluster, this is not that tool.

Requirements and limitations

You need a SQLite database that Litestream can open, a storage destination (a local path or S3), and somewhere to run the background process. Installation and configuration instructions live on the project site; the README points there rather than duplicating them. You also need a restore procedure you have actually tested — the replica exists to be restored, and that step is separate from replication.

The ongoing costs are operational: keep the background process running, watch that replication is keeping up, and accept that the source schema includes Litestream's lock table. Since the tool is beta, verify behavior on your own SQLite version and workload before depending on it. The README does not document supported platforms in detail; the acknowledgements mention OpenBSD release builds, and community notes cover running it on Kubernetes project README.

HotRepo's take

HotRepo has one recorded daily-board observation: on 2026-10-26 the repository stood at 14,532 stars with +6 that day, on the daily board trend snapshot. That single dated point cannot show whether interest is rising or fading; persistence cannot yet be judged. The repository dates to 2020, so the project is not new, but age is not evidence of maintenance quality. Before adopting, check the project site for your storage target and SQLite setup, and confirm that a restore from the replica works in your environment.