Future of Postgresql on Fly?

[cemerick]

In the course of evaluating Fly’s PG implementation, I came across this:

@kurt

Our long term goal is to “give” Postgres to a company like Supabase that is focused on a really nice dev UX for postgres itself. The launch story would be the same, but their tooling would handle things like point in time restores, forks, etc. You can use them right now with Fly apps, if you want.

This makes it sound like Fly’s PG support is really just transitory; as @kurt says, Fly databases will eventually be migrated to another provider (maybe in a done-for-you sort of way, maybe via a traditional EOL-mandated migration that users will have to handle?). Insofar as fly doesn’t (and maybe can’t, given its network infra) offer e.g. vpc peering, it seems like that would mean that databases will necessarily be accessed over the internet (implying things like egress in both directions, and potentially security concerns compared to running a DB away from public internet).

Am I misreading this, or am I speculating accurately?

[kurt]

Good question! My answer there wasn’t very nuanced. Specifically:

1. 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
2. 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?

[pier]

I’ve considered migrating to Supabase but so far I’m happy with using PG on Fly and I’d rather not incur in the issues @cemerick is pointing out (egress, latency, etc).

Realistically, the only feature I’m missing is automatic daily backups and an easy way to restore.

I guess DBA support for managing a cluster will be useful in the future… but it will be a while until I surpass what a Fly VM can offer… if that ever happens.

[brunoprietog]

Have you considered neon.tech? It would be great if there was something like that in Fly, just like you did with Upstash. Thanks!