Our most requested feature is here! We partnered with the tireless engineers at Supabase to bake Supabase into Fly.io and to become our default Postgres provider.
These Supabase databases live on Fly.io hardware, next to your apps, with tightly integrated provisioning and single sign-on via flyctl. Check out Supabase’s announcement, or our sparse but evolving documentation.
We’ll roll out private beta invites during the coming weeks. Sign up here to get one:
We love Supabase, and Supabase knows Postgres. So it was a no-brainer to partner with them to supplement our unmanaged Postgres service. But there’s more to it.
They’re also super-committed to Elixir, a language we hold dear (see our busy Phoenix Files blog category). Supabase just released supavisor, a massively performant Postgres connection pooler built from scratch in Elixir.
There so much more to say, but we’ll save it for the upcoming big launch. Please leave your feedback, questions and doubts here!
@joshua-fly For signing up using my personal org, should I provide my org name “Atridad Lahiji” or the slug “personal”?
EDIT:
Sorry one more question. Just to get clarity on pricing: we get one DB with limited resources free, and are charged for usage past that similar to the pro plan. Are we billed just for usage or the $25 USD + usage as the Supabase pro plan suggests? Just want to make sure I know what I would be getting into.
It looks like you were taken care of by support, so you should be good for both Tigris and Supabase.
You’ll be charged $25 for the Pro Plan, and usage once you pass the Pro Plan resource limits. These limits are more generous than those on the free databases.
Hey @joshua-fly! thanks for the post, just got access to the beta this morning, I am hyped. Couple of questions as I am unsure reading the docs (and there aren’t many quite yet, which makes sense).
Is the DB url private to our Fly org so only accessible within our WireGuard network?
Is the Connection Pooler public? (Seems to suggest that from the docs)
If yes to 2, can we make it private or turn it off?
If we are able to make our database completely private (within our fly network) how can we connect to them from for example local, either through SSH or some other means (like how we can with other fly features).
We want to be able to keep our DBs private unless you have the right Fly credentials.
@yharaskrik TLDR is that both DB URL are public. This decision was made to match Supabase’s existing offering.
That said, private databases are definitely high on the list of ‘next things’. Most likely, when you provision from flyctl, private will be the default. That may require foregoing the pooler, though, until it can be deployed on Fly.
Supabase databases are fully managed, so giving SSH access will probably not happen. However, databases will still be private in the sense that they’re only accessible to your Fly.io organization and to Supabase themselves.
Amazing, thanks for the prompt response. I currently have some DBs deployed on supabase (and am working on moving more over from RDS) but am in need of them being private.
No SSH is totally fine, as long as they are private to the org.
It will be $25 for a single 8gb database + $100 for point in time restores + FLY instances and volumes for the primary db and read replicas? Or does the Pro plan come with an instance?
This seems like critical functionality to me because the entire purpose of Fly.io is distributed applications. If the app is distributed but the database is not, then the performance gains are negligible.
Any guidance on when read replicas will be ready?
Also, can you explain how the connection pooler works? Will there be regional connection poolers for distributed databases? Do the current connection poolers run out of the primary data center (as configured in Fly), or somewhere else?
I’ve been entirely unable to connect to my Supabase DB, both through the DATABASE_POOLER_URL and DATABASE_URL
I keep getting this error: connection to server at "fly-0-ewr.pooler.supabase.com" (52.45.94.125), port 6543 failed: error received from server in SCRAM exchange: Wrong password
It shouldn’t be an IPv6 issue, because I’m using the connection pooler.
I’ve used the Supabase UI to reset the database password and that’s not allowing me to connect, either.
The hope is for read replicas to be ready for GA or soon after, though that’s up to Supabase! It’s definitely high on the list.
Supabase docs suggest that each replica gets its own dedicated, regional pooler. That should work the same for Fly.io DBs once the feature is released. That said, poolers currently run on AWS, so the performance profile will vary depending on the distance between AWS and Fly in those regions. You can get a general idea of per-region latency in our RTT tracking app.
The Pro Plan is an independent cost that allows you to provision any number of databases, under the per-organization limits specified on the pricing page. After you pass those limits, you’d pay for additional usage.
You won’t pay more for Fly VMs. The pricing you see in Supabase is exactly what Fly will charge you.
UPDATE: I updated this message to reflect that the Supabase Pro plan limits are per-organization, not per-project. Supabase sums up used database space from all projects in an organization. If the sum exceeds 8gb, you pay 0.125 $ per GB.
@joshua-fly hey Joshua, revitalizing a reply I made earlier that you already replied to (thank you!) to hopefully get some more info.
Does Fly/Supabase have any estimate on when Network restrictions and/or private DBs within our wireguard network will be supported? once that is support I can finally move our last environment (that is comprised on a couple apps and dbs) from AWS to Fly! Which I would love to do obviously.
Having the DB instances locked down in the private network is exactly the feature we’re waiting for as well. We’re not dissatisfied with RDS for managed Postgres, except for the difficulty of securely connecting to them from our Fly.io apps.
I don’t have any experience with Supabase, but I’m under the impression, that their main focus is being a Firebase alternative (e.g. cloud functions), and not AWS RDS alternative (hence lack of HA/replicas). That makes me think, that Supabase might not be the best place for managed PG. I might be wrong though.
Private database support is next on our list. Once Supabase gets past IPv4 deprecation we’ll take a look at supporting private databases.
It would be easier to support completely private databases than network restrictions, since getting a real client IP behind the Fly.io proxy requires proxy protocol support, and Postgres doesn’t support it natively.
completely private databases would be totally fine! Just something more than having it open to the internet! Thanks @joshua-fly for keeping us updated!
We went with Supabase because they definitely plan to offer read replicas and HA on Fly.io. I can’t comment on a timeline, but I’m as excited as anyone about it
