HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
benbjohnson
litestream
Go2021–2026
benbjohnson / litestream

litestream

Streaming replication for SQLite.

51Distinct people
64Mentions
1Explicit recommenders
14.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Streaming replication for SQLite.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

sqlite+litestream [1] is fantastic, i highly recommend it. I use it with pocketbase and it is a delightful and very productive setup. This guide [2] is for an older version of…

dtkav used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year64 dated mentions

Observed mentions: 2021-01-22 08:24:25 UTC to 2026-10-12 19:33:21 UTC.

051015202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 19 mentions; 6 submissions, 13 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 16 mentions; 3 submissions, 13 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 16 mentions; 2 submissions, 14 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC19613
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC16313
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC404
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC413
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC16214
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC514

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Litestream Litestream is a standalone disaster recovery tool for SQLite. It runs as a background process and safely replicates changes incrementally to another file or S3. Litestream only communicates with SQLite through the SQLite API so it will not corrupt your database. If you need support or have ideas for improving Litestream, please visit GitHub Issues. Please visit the Litestream web site for installation instructions and documentation. If you find this project interesting, please consider starring the project on GitHub. Source database changes When Litestream begins replicating a database, it creates an internal _litestream_lock table in the source SQLite database. This is expected and safe to leave in place. Litestream uses the table to acquire SQLite's write lock while coordinating synchronization around WAL checkpoints. The writes occur in transactions that are rolled back, so Litestream does not leave rows in the table. The table is part of the source database, not a separate table in the replica destination. Because the source schema is backed up, restored databases also contain it. Its creation changes the source database schema and can change its page count or bytes, so a database under Litestream should not be expected to remain byte-identical to its pre-Litestream state. Do not drop _litestream_lock while Litestream is running. Synchronization around a checkpoint can fail until Litestream reinitializes the database. Restarting Litestream recreates the missing table automatically. Stopping replication litestream replicate attempts a graceful shutdown on SIGINT or SIGTERM. The top-level shutdown-timeout configuration setting limits the entire shutdown, including waiting for startup, an exec process, and closing databases and replicas. It defaults to 30s; set a longer duration when final replication needs more time. Invalid or nonpositive values produce a warning and use the default. A second SIGINT or SIGTERM interrupts shutdown immediately. A timeout or interruption exits with an error because the final replica sync may be incomplete. This process-level bound also applies when a replica connection stops responding during startup. Cancellation of the calling context also starts a bounded graceful shutdown, using a fresh context for final replication. The existing shutdown-sync-timeout setting still controls each database's final replica sync retries within this overall limit. The process-level bound does not apply to callers of the Go library. Contributing We welcome bug reports, fixes, and patches! Please see our Contributing Guide for details on how to contribute. Security Please do not open a public issue for security vulnerabilities. Report them privately through GitHub's private vulnerability reporting, which keeps the report visible only to you and the maintainers until a fix is released. See our Security Policy for what to include and what to expect. Acknowledgements I want to give special thanks to individuals who invest much of their time and energy into the project to help make it better: Thanks to Cory LaNou for giving early feedback and testing when Litestream was still pre-release. Thanks to Michael Lynch for digging into issues and contributing to the documentation. Thanks to Kurt Mackey for feedback and testing. Thanks to Sam Weston for figuring out how to run Litestream on Kubernetes and writing up the docs for it. Thanks to Rafael & Jungle Boogie for helping to get OpenBSD release builds working. Thanks to Simon Gottschlag, Marin,Victor Björklund, Jonathan Beri Yuri, Nathan Probst, Yann Coleu, and Nicholas Grilly for frequent feedback, testing, & support. Huge thanks to fly.io for their support and for contributing credits for testing and development!
Read the full README on GitHub

What Hacker News says

64 sources
Thank you for sharing, if you don't mind can you share some Go+SQLite leanings as someone actually pulling this off? 1) How do you do backups? Do you use github.com/benbjohnson/litestream? CRON job backup with rsync? 2) Any issues with large databases and many clients? Is there a TPS or DB size where SQLite becomes problematic? 3) How do you deploy new binaries and safely shutdown the old instance? Caddy change to route to new binary + Go's HTTP server graceful-shutdown on old instance? 4) Do you use a pure-Go SQLite lib or one of the CGO libs?
In SQLite is all you need for durable workflows
Oh, thanks for the correction! I can't believe I never noticed that. I've updated the post. After your comment, I thought, "Oh, I should contribute a PR to the repo to add the Docker badge so the Docker image is obvious to everyone," but it turns out the badge has been right there for four years.[0] What I suspect happened is that I tried to use the Litestream Docker image once, discovered that image was amd64-only (until 0.3.9), so I didn't use it because I needed ARM, and then I just kept copy/pasting my workaround from project to project. [0] https://github.com/benbjohnson/litestream/commit/6acfbcbc64d...
In Hold Off on Litestream 0.5.0
>Thx. The only problem I have with litestream binary is ~31Mb !? Where are you seeing a 31 MB binary? Latest releases are 10-11 MB.[0] >This why I prefer to take backup stuff in a side container, eg: https://github.com/atrakic/gin-sqlite/blob/main/compose.yml Yeah, I agree that's cleaner, but once you're dealing with multiple containers, it's a big step up in complexity, and you can't do the simple install on places like Fly.io and Lightsail. >As a side note, you might consider revisiting your dockerfiles and skip litestream build steps, eg. in your final stage just add line like this: >COPY --from=litestream/litestream /usr/local/bin/litestream /bin/litestream Ah, thanks! The litestream Docker image is new as of 0.5.0. [0] https://github.com/benbjohnson/litestream/releases
In Litestream v0.5.0

Showing the 15 most recent of 64 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.