We wrote a blog post about this:

https://fly.io/blog/how-we-built-fly-postgres/

If I'm understanding correctly, Fly Postgres isn't too different from something like Postgres on Heroku? It's a single instance/cluster in a single location.

I don't think that's correct at all. Heroku Postgres has a central control plane that is monitoring availability and orchestrating things. There are continual health checks that go back to Heroku. In the event of unavailability it sets off a page to the on-call engineer to investigate if systems haven't restored availability.

My understanding of Fly Postgres is they put a lot into the tools to orchestrate, but there is not centralized monitoring and in the event of a failure it is up to you to realize and remediate.

Disclaimer: Was part of the team that built Heroku Postgres, and know the Fly team pretty well but don't personally use Fly Postgres so it's my understanding from the team. We've had a number of customers leverage Crunchy Bridge (build by a lot of the original Heroku Postgres team) use us for the managed Postgres connected to fly.io via Tailscale.

I think you're talking mostly about Heroku being a managed service while Fly Postgres is unmanaged. It sounds like the new managed Postgres in partnership with Supabase is managed in a similar way where Supabase would handle health checks and all that?

Management is a huge difference of course, but I was mostly asking about the database from the point of view of a user of the database. It doesn't sounds like Fly Postgres is doing anything like running your database globally - you still have single instance of the database.

Apologies if I'm missing some details. I intentionally try to stay out of the technical devops type stuff. I'm the kind of person who just pays Heroku for a Postgres and doesn't think much about it after that.

For what it's worth, Fly Postgres isn't single-instance or single-location. (But it's also not managed, which is a big deal).

How does that work? Does Fly just give you the logins for all of the Postgres servers you provision and you manage it yourself?

See the blog post linked upthread.

I think a bit of confusion on Fly Postgres vs. the Supabase offering. The earlier was unmanaged on Fly infra.

I'm not sure the full details on supabase as it's more recent.

This is a pretty good breakdown of various database providers and in particular a lot paired with Fly - https://dancroak.com/webstack/

Yeah! One way to think about it that is almost (not perfectly) correct is that you could build and run all of Fly Postgres yourself; it's almost just a Fly App configuration.