https://github.com/benbjohnson/litestream/releases/tag/v0.5....
[0] https://fly.io/blog/litestream-v050-is-here/#the-ltx-file-fo...
Thanks to mtlynch and everyone else who has submitted bug reports. We're squashing issues and working to get everything stable as quickly as possible.
All things considered, this is probably just a tiny footnote in this software's life.
That alone should hint everyone it was a big leap.
https://fly.io/blog/litestream-revamped/#lightweight-read-re...
But the concept is really cool, and it's workable. I already have a version that mostly works.
https://github.com/ncruces/go-sqlite3/tree/litestream/litest...
With Litestream v0.5.0 doing the replication, you'll get some transient read failures that really shouldn't happen.
If you build Litestream from head (or wait for v0.5.1), that'll be fixed. You'll still have similar issues around the time of a snapshot, if you keep only one snapshot.
Other than that, I'm pretty confident it just works. But the performance probably sucks. I need to add a layer of caching. But that's it.
Livestream, sqlite and caddy are incredibly at making single box/vps ops a breeze.
There’s been an official Litestream container image for over 3 years at this point (since version 0.3.4, it’s at the same Docker Hub as 0.5.0).
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...
emschwartz•3h ago