Today we’re announcing the private beta of Fly Managed MySQL. Please sign up to our waitlist. We’ll send invites as soon as possible. We need your feedback!
You’ve been telling us that Fly.io is missing a good database story. We couldn’t agree more.
So, we’ve been furiously hacking away at our own, Fly-managed database services. You may have noticed our recent improvements to Fly Postgres and Fly Kubernetes. These updates were part of the drive towards managed databases.
A few details:
Yes, databases are fully managed - we’ll keep them up, backed up, maintained and monitor their performance
Databases run highly-available by default - no single-node services
Databases are locked down to your Fly organization’s private network
Postgres is coming soon - stay tuned
Let us know: what do you need from managed databases on Fly.io?
I don’t know if this is in the cards, but what I most want is a pay-as-you-go pricing model with no floor. Charge whatever is reasonable per GB of storage, number of queries, etc., but for example, I don’t like Supabase’s pricing model of free for 500MB, but 501MB costs $25/mo.
A small side question about postgres you mentioned in your post. Is now supabase going to be the managed database service for fly or are you pushing more updates to bring the postgres-flex system to a managed database service. Would be great to know!
It would be ideal if replicas didn’t have to use the same instance type as the primary. I’d like to allocate a more powerful instance (better CPU, more RAM) for the primary since it handles most of the workload, and use cheaper instances for the replicas. In the event of a failover, the replica instance could be upgraded to match the primary’s specs.
Currently, it feels wasteful to pay for two powerful replicas that mostly sit idle in case of a server failure. If this change were implemented, I could either invest in a stronger primary instance or deploy more replicas for better high availability, all within the same budget.
If scale-to-zero is implemented, and if the db’s VM(s) and the app’s VM(s) are both suspended, it would be awesome if when a request to the app comes in, if Fly’s Proxy could begin resuming the db’s VM(s) and the app’s VM in parallel, rather than waiting for the resumed app to make a db request before starting to resume the db.
We’re not ruling out Supabase as an alternative, but won’t be putting it into production yet. We’re waiting for their HA support, which is a requirement on for production-grade DBs on Fly.io. Meanwhile, we’re working on our own. More details will emerge soon from our PG team!
This is an interesting request. For a managed DB though, do you feel the value comes from paying for the underlying resources, or the fact that the service is monitored and maintained?
Also, this kind of setup could be tricky in a real production scenario. If your replicas are too underpowered, they can lag, and may not be able to handle failover in an emergency. Even if you bump its resources at that time, you’d like see some service disruption.
The tricky part here is ‘managed’. Most managed DB pricing models are similar, because they’re baking in support, monitoring, etc. Are there examples out there of a managed DB that offers a pricing model without a floor?
Managed Postgres in private network would be amazing. I’d love this asap. Tbh this is the biggest concern preventing me from hosting my whole infra stack on Fly.io.
The collaboration with Supabase is nice. Or it can be like Neon that offers serverless scale-to-zero Postgres.
For feature requests, I’d like the ability to schedule periodic snapshots that can be uploaded directly to Tigris or S3. Having the managed backups that can be quickly restored is nice, but having the separate offsite snapshots is peace of mind.
Yay! I am so excited. I am about to move our last system from AWS to Fly but need the DB to be locked within our internal network (no public IPs or ports) so I am using the existing fly pg stuff, but would much rather it be managed.
Exciting! I’m more interested in the Postgres version personally, but I will also happily use perona based MySQL if it is fully managed and reasonably priced.
How will minor and major version upgrades be handled?
We haven’t worked this out yet, but I think minor upgrades would be handled automatically. Major upgrades aren’t on our radar yet. Do you have some thoughts?
Are you planning to support multi-region replicas? I would like to have replicas deployed in multiple regions alongside my fly machines, for extremely low latency reads . This is something that seems sorely lacking in every cloud database provider except for Turso, which locks you into SQLite.
I think that going from one LTS (e.g., 8.4) to the next LTS (e.g., 9.7) would need to be customer-initiated in case app code requires changes. This means once 9.7 comes out, Fly would need to support both 8.4 (for existing databases) and 9.7 (for new databases) for some period of time, and provide some API/UI for customers to upgrade from 8.4 to 9.7 when they’re ready.
The question for Fly is how long to keep supporting 8.4. I think the choices are:
For 1 year after 9.7 is released. This gives customers one year in which to upgrade their apps. I think any less is too short since many organizations need to budget/plan a year out.
Until 10.7 is released (approximately 2 years after 9.7 is released). This would give customers the maximum amount of time in which to upgrade without requiring Fly to support more than 2 LTS versions at a time.
5 years from 8.4’s release (approximately 3 years after 9.7 is released). This would match MySQL’s Premiere Support duration, but it would mean Fly would need to support 3 LTS versions at a time.
8 years from 8.4’s release (approximately 6 years after 9.7 is released). This would match MySQL’s Extended Support duration, but it would mean Fly would need to support 4 LTS versions at a time.
Whichever option above you go with, then there’s the question of what do you do when you decommision an LTS version but some customer databases are still on that old version. I think the choices are:
Stop accepting traffic to those databases. This will break the customer’s app in an obvious way.
Auto-upgrade those databases to the next LTS. This might break the customer’s app in a subtle way.
Ideally, minor version upgrades can be handled with no downtime other than rolling restarts and connection cycling.
Major upgrades are trickier since they have breaking changes, and even the big clouds don’t make those transparent.
I’d love to see Fly provide some kind of migration service akin to AWS DMS, or integrate with a third party one, so you can create a new cluster, set up continuous replication, and then flip over once everything is in sync. It still requires app awareness and dual reads and/or writes in-app depending on the architecture of the app itself, but it minimizes the downtime required to go to a new major version.
DMS was a critical component of a migration I did for a service handling approximately 1.5 million requests per second; End to end it took two engineers two weeks to execute - it would have taken months without it.
. This is something that seems sorely lacking in every cloud database provider except for