Last year we released a managed service called LiteFS Cloud that continuously backs up LiteFS clusters. We’ve decided to wind it down. LiteFS Cloud will continue to be available until October 15, 2024.
LiteFS Will Keep Working
LiteFS is an open-source project that runs directly in your own instances. We’re not sunsetting LiteFS itself! LiteFS is great; we use it extensively ourselves. But most LiteFS users don’t use LiteFS Cloud, so we’re going to stop running it.
Disconnecting from LiteFS Cloud
LiteFS is designed to hold transaction files until they can be safely replicated to LiteFS Cloud, so you should disable this feature before the service shuts down in October. It’s easy: just unset your LiteFS Cloud environment variable.
$ fly secrets unset LITEFS_CLOUD_TOKEN
This will redeploy your app without being connected to LiteFS Cloud.
Disaster Recovery Without LiteFS Cloud
There are two good options.
LiteFS + Litestream
You can use Litestream to maintain your own backups to an S3-compatible object storage such as Tigris. That’s what we do internally. If you’re running a static primary, you can point Litestream at your primary node in your cluster.
Turso
If you’re interested in running a fully-managed SQLite service, we like Turso. You can find more information on their Quick Start page.
Oh no, thanks for making LiteFS Cloud @benbjohnson. It’s sad it didn’t take off. Are you planning to create a “self-hosting speed run” or something in the docs to make the transition off LiteFS Cloud smoother? That would be much appreciated.
Is this just a pricing problem? I didn’t adopt it myself as I didn’t have enough data writes to justify it, but that will probably start changing in the next year. I’m curious what the adoption rate would be if there was no $5/month base fee and just with pay as you go.
I think adoption rate isn’t necessarily the issue, it’s revenue.
If you have 100 customers paying $5/month and then switch to having 2000 customers paying $0.25/month in actual usage, you have 20x your number of users but still the same amount of revenue (and likely higher costs from the higher number of users).
You’d need some users to have high usage and if there’s hardly any users above that $5/month currently then switching to pay-as-you-go would likely end up with a drop in revenue.
I’m sure they did the math and figured it wasn’t worth it, but there’s definitely some cause/effect going on here with pricing. Would lowering the minimum cost be a better first step rather than shuttering it? Can it just run or is the operational cost too high?
Lifefs cloud was kind of the missing piece to the sqlite resiliency story. Litestream is ok, but requires a fixed primary.
Looks like Fly is not all-in on sqlite anymore. I’m sad.
Removing a price floor would certainly add users but there’s an increased support cost if we did that. It’s hard to run a purely pay-as-you-go service, especially for a naturally low cost option like SQLite, so some kind of base price is necessary.
LiteFS and LiteFS Cloud are awesome products. I’m sad that the pricing/business model didn’t work out. In case you want to give it a go again some time in the future, here’s some ideas that might help align price to value. I have no idea how any of these would perform in practice, they’re just some off-the-cuff ideas:
Let’s say you got people in the door at $0.50/GB with no base price. You could give that some basic level of backup retention (say 30 days, or maybe even less like 7 days) and PITR granularity (say 5 minutes, or maybe longer like 1 hour). Then you can offer higher tiers, like $1.50/GB to increase backup retention to 1 year or $2.50/GB to increase PITR granularity to 30 seconds or whatever a reasonable technical limit is.
Implementing Object Storage · Issue #327 · superfly/litefs · GitHub would get at least some customers using larger “database” sizes and therefore paying more. It might not lead to hundreds of GB, since at that volume the customer would have a lot of incentive to use S3 for those objects, but I think there would be a lot of use cases for up to 5GB or so of files, for which the convenience of keeping them synchronized (and PITR’able) with the database is worth the higher per-GB cost over S3.
You could (and should!) charge extra for high write throughput. But that then requires SQLite to be a good fit for high write throughput applications. If LiteFS added support for HC-tree, that could perhaps attract more customers with high write throughput applications.
I feel like I would have gotten around to adopting LiteFS Cloud eventually – I only found out about SQLite and LiteFS Cloud about 6-7 months ago, so this seems pretty quick for things to be sunsetting. I thought for sure we had a decade-long horizon to see SQLite become accepted more broadly, since I’ve noticed a lot of incredulity around it, but on the other hand speed makes the future move fast.
@benbjohnson Any chance the LiteFS Cloud code will be open sourced? I’m guessing the server it backs up to isn’t as simple as an S3-compatible server?
Failing that, could you explain a bit more how to get Litestream running? I’m struggling to understand why it requires a static LiteFS primary rather than just being a process run on any one of the replicas.
I have a somewhat high traffic litefs app with 10 transactions a second with many writes inside those. LiteFS Cloud would stop deleting ltx files and start growing the disk infinitely. It took many attempts with support and it would continue growing, while the sqlite db itself stayed small (this has a lot of adding and removing of data but stays near a constant small size)
After finally removing the litefs cloud token, the disk space stopped growing in size infinitely and has been stable for weeks now.
I feel there must not be enough users with high traffic, or the price turned a lot of people off.
I will say I am a little worried about some of these pricing changes and deprecations happening so fast on the platform, my bosses will be pretty mad at me if fly becomes unusable because of pricing and features that worked at the time of my estimates.
On another app I need liteFS cloud much more, and I would have expected at least a guide on how to use litestream when you are using promote: true on litefs, to at least give us a way off it without having to figure stuff out on our own.
I’m also a LiteFS Cloud user and would love a tutorial on how to transition from LiteFS Cloud to Litestream + Tigris on Fly or something similar. LiteFS Cloud has been super useful to me - both backups and the ability to query the database quickly. I’m sad to see it go. I would go so far as to say that it was one of the reasons I chose to use Fly as a backend / infrastructure neophyte.
Would love to see a replacement for LiteFS Cloud. Having a ui to query the database was always really nice, and having backups was great (especially after i just lost data last night on a new project using LiteFS without LiteFS Cloud).
I understand that not many folks went in on LiteFS Cloud so the message is “not many of Fly’s customers impacted”, but this is pretty lacking for those of us that did take a chance on it.
As other folks have mentioned, this post only talks about how to transition with the static lease case. In Fly’s own speedrun, the consul-based path is heavily promoted but it’s not mentioned at all in here.
At this point, I just want to figure out how to move forward and get a different backup solution in place before the shutoff. It’d help to understand have some set of these things for the rest of us to piece this back together:
some guidance on if litestream with litefs is viable with dynamic leases, or if the easiest path is to give up on that and run our systems with a static primary (is this very likely to work if you just make sure litestream replication on different nodes don’t clobber each other? or am I going to run into a ton of trouble)
some guidance on how to use litestream and litefs together in general (all I could really find was this “[it] should work fine”, but it’d help to have a quick guide on “here’s how to replicate, then do a restore from scratch” i.e. a replacement for this disaster recovery doc)
Like others, I’ve recently started using LiteFS Cloud. I probably don’t need all of its features, but the practicality of it still sold me on it. Sad to see it go that quickly.
I would also like to see more resources for migrating to the solutions mentioned, to help those affected by the discontinuation of the service.
I created a quick backup service that backs my Litefs db up to Tigris for anyone who’s interested. It’s a really quick implementation, so any advice / comments / improvements would be appreciated.
This is exactly my concern. I would prefer to go this route, but I don’t want to use a static-lease because of the DR aspect.
Really would appreciate the best path for getting off LiteFS Cloud and replacing with Litestream or other.
I REALLY REALLY like LiteFS Cloud. Using the export command to download it locally has been amazing, as I generate some files offline, and requently have to download the lastest production copy.
Without a external source, I have to run litefs export on the machine, and then copy it out, which is more work.
Would love some more guidance for non static leases.
