Wondering if there is already any discussion of (or interest in) using libSQL (GitHub - tursodatabase/libsql: libSQL is a fork of SQLite that is both Open Source, and Open Contributions.) rather than sqlite as the backend and syncing to Turso(https://turso.tech/) (if I was self hosting I think this is how I would want to do it) I don’t know much about Atuin yet. But this seems like a natural use case to me.
I’m not too clear on why libsql could be better than SQLite, and what the benefits of switching would be?
LibSQL is network-aware. So easy to sync. Remote replication is built in.
A really key part of our sync is
- Support offline writes
- Support multiple writers, some offline, some offline, for an infinite amount of time
- End to end encryption
And it’s unclear if Turso/libsql solve any of those things. Even if they do, our sync generally has very few issues + replacing it with a commercial service (?) does not seem to be much of a value add
I’ll try some coding myself and getting more familiar with Atuin before I try convincing anyone. Just wanted to make sure I wasn’t reinventing the wheel. but this might be interesting to anyone who finds this thread.
Fwiw, reading that post - it sounds like e2e encryption is not a goal of theirs. That makes it a non-starter for us
This is the best I could find regarding encryption. Again I don’t know enough to argue about it but it seems like it would be a good fit to me so far. Hmmm it won’t let me me post the link but if you do a google search for “Fully Open Source Encryption for SQLite” you’ll probably find the blog post of why I think they are.
Thanks for the suggestion. Right now we won’t be migrating to Turso/libSQL.
Offline writes, multi‑writer sync, and E2E encryption are hard requirements for Atuin. Our current SQLite‑based sync already delivers those.
Turso’s offline sync is still in public beta, so swapping a battle‑tested system for something pre‑release would add risk without any clear upside. Also, Turso has had multiple publicly acknowledged data loss incidents, which makes us cautious about adopting it for core data handling.
If their offering matures and supports full E2E, we can revisit. For now we’re not planning to review PRs in this area. Feel free to experiment in a fork if you’d like.
1 Like