postgres-ha VS fly-ruby

Fly Postgres is just a Fly.io app. You can see the source code for it right here:

https://github.com/fly-apps/postgres-ha

It has some direct `flyctl` integration (which is also open source), but it's not doing anything you can't do yourself if you want.

We do not! You have full administrative access to your postgres. You can create offsite replicas, or even fork the Postgres app we use and deploy over your Fly.io installed postgres: https://github.com/fly-apps/postgres-ha

RDS preventing external streaming replicas is the most annoying thing ever.

Our Postgres is not an RDS replacement. Lots of devs use RDS with Fly. In fact, Postgres on Fly is just a normal Fly app: https://github.com/fly-apps/postgres-ha

Ultimately, we think devs are better off if managed database services come from companies who specialize in those DBs. First party managed DBs trend towards mediocre, all the interesting Postgres features come from Heroku/Crunchy/Timescale/Supabase.

So we're "saving" managed Postgres for one of those folks. For the most part, they're more interested in giving AWS money because very large potential customers do. At some point, though, we'll be big enough to be attractive to DB companies.

Our postgres clusters are just a Fly app: https://github.com/fly-apps/postgres-ha

You could run your own PG by modifying that app. Right now we're calling it "automated" and not managed, though. All alerts about health and other issues go straight to customers, we don't have DBAs that will touch these things yet.

Yes, it's Ruby on Rails! I'm using Hotwired on the frontend, which has been great for making discussions real-time while minimizing complexity. I'm hosting on Fly.io - I had used Render for a prior product (https://postcard.page), and found Render slow. Fly lets me set up multiple data centers, and they have an elegant little Ruby gem [1] to enable multi-region support on Rails without much fuss.

[1] https://github.com/superfly/fly-ruby

Fly is compelling enough to use without all the global deployment options they offer[1] but it's assuring to know if you ever do need to deploy globally, they can support that better than most.

[1] - https://github.com/superfly/fly-ruby

This is a good way to do it. Catching errors lets us reliably ship a library that makes this work for almost everyone, but it's not right for all apps: https://github.com/soupedup/fly-rails/blob/main/lib/fly-rail...