However, in the event that all nodes shutdown at the same time, the database would be lost. That’s no good.
To protect against this, you’re encouraged to use volumes. This allows nodes to retain their data between restarts. Please see the Volumes documentation for more information.
Question: Are there any plans to bake this in to the platform so that end users of SQLite/Litefs aren’t concerned with persisting their data?
My initial impression of the offering was that Litefs would allow me to use SQLite as a traditional database, saving network latency (which is true!); however, I think having to consider persistence of SQLite makes me think of it more as a globally distributed cache that is multi-region by default.
LiteFS cannot overcome the fact that Fly VMs have ephemeral storage (like EC2 does). Volumes (analogous to EBS) that you must attach are disks you’d attach if you needed persistent storage for any reason (let alone LiteFS). Even without volumes, LiteFS can still holds its own if multiple-VMs go down. Just not when ALL VMs go down.
I’ve been calling for it (a16z has been calling for it): Fly needs to have a managed database offering, rather than merely automated ones. LiteFS could be it. Or not. Not sure what their plans are, really.
Tough, if you’re looking for a fully-managed database, there are plenty like PlanetScale, Aurora Serverless v2, Cloudflare D1 etc.
hey Nick, good question. Yes, we do have plans for a more managed offering for SQLite persistence. Right now we’re trying to make LiteFS solid before we add on additional services. There are a few more pieces such as WAL support (#14) and write forwarding (#56) that we need to wrap up before we can add a managed service.