Good question! My answer there wasn’t very nuanced. Specifically:
- We would not migrate you to another provider. You would have the option to spin up a higher touch, fully featured Postgres-as-a-Service
- One requirement we have for anyone who brings fully managed to Postgres-as-a-Service to Fly.io is that they run on our hardware and they make their DB accessible over your private network.
If you look at what we did with Upstash for Redis, you can see how this would play out. It’s totally ok to run Redis on Fly yourself, but if you want a managed Redis you can add that to your app (it has different pricing, a different level of support, etc).
When you add Upstash Redis, we actually provision a private IP in your Fly network and then assign it to the Upstash service. Your Upstash Redis isn’t accessible to the internet.
For Postgres specifically, you should look at what we’re doing today as automated Postgres implemented as a Fly app. We’re still improving the Postgres automation features, it’ll be something we think is important forever.
What automated Postgres on Fly is lacking is hands on DBA support if something goes sideways. If your Postgres cluster breaks, we don’t login and do work to make it happy again, that’s largely up to you. This is actually what most developers need, believe it or not.
People do want an option for a managed Postgres, however. Lots of devs want to know someone will login and fix their DB cluster if something goes wrong. They want this (and will pay a lot of extra money for it) even if nothing ever goes wrong.
Devs also want more specific Postgres features we may never get around to building. Things like zero config point in time restore, DB forking, etc, etc. Our automated Postgres app is vanilla and doesn’t have a lot of power user PG features. You can fork it and add stuff yourself, which is cool, but it’s not the same thing as a managed service with bespoke features.
Does that make more sense?