LiteFS started as a way to distribute SQLite geographically but why not distribute databases between services? Building APIs is a PITA so we skipped it and just replicated the database instead.
And that opened up some more interesting use cases!
@benbjohnson
Having trouble understanding how’s it different than creating a readonly user in a db with centralized endpoint.
At the end, another point of the API is to be a rendezvous point for cases that require consistency around reading from X and writing to Y. I guess it’s only useful…
@ahmetb
One important difference is being able to offload compute to the client. Their queries can run against their local copies rather than the upstream database instance.
You could do the same thing with MySQL or PG replication but it's pretty simple to do with LiteFS.
@benbjohnson
That’s similar to what my team at
@AppsFlyer
does for some slow moving data. Setting up LiteFS proved tricky for us in terms of security and k8s usage so we settled for periodic polling on a “source” file. I’ll cover this briefly during my
@api_conference
#Berlin
talk in October.
@ZvikaAlmog
@AppsFlyer
@api_conference
I'd be curious what your security & kubernetes issues were. We have a built-in Wireguard network so I haven't added anything like mTLS yet. The Kubernetes side definitely needs some work and it's something I'm interested in supporting.
@ianduvall_
I think client-side querying could have a lot of potential in a B2B space where someone wants flexible, offline access to their data for analysis. We're actually working on a version that can compile to WASM and run in-browser.
@benbjohnson
We are working right now to replace KV with SQLite and LiteFS. SQLite + LiteFS is also a strong contender to replace Redis Stream / Rabbit MQ. But we have 200+ Windows Clients sending data to Linux. Any plans for a LiteFS Windows Service just like Litestream?