Found this comment by @kurt on HN mentioning a possible collaboration betwen Fly and Crunchy Data.
Their PG service is top notch. If I’m not mistaken some core PG maintainers actually work there.
Is this ever going to happen?
I’m not really interested in the Supabase integration since it requires paying for the whole enchilada (auth, storage, etc) which I really don’t care about.
@pier seems like the current strategy/priority is Fly’s own managed MySQL and Postgres. MySQL is already in private beta, and I hope Postgres will follow. I guess those partnerships didn’t work out.
Thanks @Elder I wasn’t aware Fly was working on a managed Postgres service.
@pier, this is from the managed mysql announcement. Fingers crossed.
This is cool.
I wonder what made @kurt change his mind since he wrote:
People like us (Fly.io) will end up either building very mediocre DB offerings or collaborating with DB companies to ship stuff that’s substantially better than RDS. I’m looking forward to it. Down with mediocre DB services.
There were brief and easily overlooked comments elsewhere indicating that Supabase is non-trivial to port to Fly.io’s “always ≥2 machines” reliability model. Possibly this is an interim measure until the cycle (eventually) turns for PG startups…
(Also, Fly Kubernetes might have changed the in-house calculations, somewhat.)
The preceding paragraph, about the side effects of over-bundling PaaS, is the more insightful and telling of the two—in my opinion:
mrkurt:
I think the most interesting part of this is the PaaS disaggregation. Heroku built an exceptionally good Postgres service. They could not have done that with multiple DBs. Even their redis is pretty meh.
It looks like this overall reasoning lives on, albeit stated in a much more dilute way—and (like you pointed out) with tactical adjustments in one corner…
https://fly.io/developer-cloud
I hope the “distributed filesystems” part in particular pans out, 
…
So, we’re not ruling out the integrations with Supabase, or anyone else. But as @pier pointed out, our platform presents a more challenging HA landscape than something like AWS, where most providers rely on network-attached disks.
Yes, building managed databases is a high bar we’ve set for ourselves. But we have plenty of experience with them on staff. And, this path will allow us to cut out all the back-and-forth that inevitably accompanies a 3rd party integration (reconciling APIs, billing, support, etc).
We’re not shouting it from the rooftops, but most likely PG will come before MySQL based on the demand we see.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
