Litestream vs Borela

Litestream is excellent SQLite replication. Borela is the managed verification layer around backup freshness, restore drills, and alerts.

The short version

Litestream is the tool I would reach for first if I were building SQLite replication myself. It is focused, mature, and exactly the right shape for streaming SQLite changes to object storage.

Borela is not trying to replace that core. Borela uses Litestream under the hood, then wraps the operational pieces that solo operators tend to postpone: managed storage credentials, a dashboard, stale-backup monitoring, restore drills, integrity checks, table and row counts, and email alerts.

What Litestream gives you

Litestream gives you continuous replication and point-in-time restore. You configure a replica, run the process beside your application, and restore when needed. For a developer comfortable with object storage, service files, retention, and monitoring, that is a very strong foundation.

The tradeoff is that Litestream does not run your operations process. It will not choose your alert thresholds, email you when your production backup is stale, create customer-scoped credentials, or prove every week that your latest backup can restore.

What Borela adds

Borela turns the replication primitive into a managed backup loop. The agent reports backup freshness to the cloud. The dashboard shows the latest heartbeat, latest backup, storage usage, and restore commands. The drill worker restores backups in isolation and records whether they passed.

That sounds small until you are tired. Most backup failures are not exotic database theory. They are normal operational drift: a bad token, a moved file, a service that stopped after reboot, a restore command nobody has run since setup.

Use Litestream directly when

Use Litestream directly when you want maximum control and are willing to own the full runbook. That means provisioning storage, rotating credentials, writing systemd units, checking logs, setting up alerts, documenting restore commands, and scheduling restore drills.

If you enjoy that work or already have infrastructure for it, Litestream alone may be the better fit. It is simple, transparent, and does not put another service in the trust path.

Use Borela when

Use Borela when the app matters enough to need proof, but not enough to justify a custom backup operations stack. That is a common place for small SaaS products, Rails SQLite apps, Coolify deployments, internal tools, and AI-generated apps that suddenly have real users.

Borela is not a substitute for understanding your database. It is the boring weekly loop around it: is the backup fresh, can it restore, did the restore pass, and will someone hear about failure?

Migration path

If you already run Litestream, keep that mental model. The simple Borela path lets Borela manage the replica URL and credentials. Advanced users can bring their own replica URL and use Borela for visibility, with the caveat that cloud-side drills need read access to the storage they are verifying.

The practical migration is to add Borela to one non-critical project first, compare the restore reports with your existing process, then decide whether the managed loop is worth it.