Fly Postgres, managed by Supabase

We're launching Fly Postgres, a managed Postgres offering by Supabase and Fly.io.

Fly Postgres databases launch on Fly.io's edge computing platform from any of their 37+ locations. You get everything you expect from a Supabase managed database:

• a full-featured Postgres database with over 40+ extensions
• pgvector support for Vector/AI workloads
• Supavisor, our Postgres connection pooler
• Daily backups and point-in-time recovery
• Branching, observability, and migrations
• A dashboard for managing your database
• Auto-generated Data APIs:
  • REST (using PostgREST)
  • GraphQL (using pg_graphql)

This is deployed within the Fly infrastructure, making it the fastest Postgres database for your data intensive applications deployed on Fly.

Managing expectations#

Before you get too excited, this will be a progressive rollout. It turns out that building inter-company integrations is a lot of work when you factor in billing, support handoff, and educating Supabase staff on how to understand sandwich analogies.

We've been working with a few early testers and we have some bugs to iron out. You can sign up for the waitlist if you want to help with testing. We'll accept more testers next month, and we'll communicate more release timelines as soon as we're confident that your data is safe.

Supabase + Fly = SupaFly?#

We're excited about what this partnership means for 2024. Namely, distributing Postgres across the planet. The Firecracker VM gives us some neat ideas for Postgres. Integrating with Fly also puts a bunch of easy-to-spin-up compute resources right next to the database. That sounds like fun.

Managed vs unmanaged Postgres#

Fly's current Postgres offering is unmanaged. This means that you're responsible for handling scaling, point-in-time backups, replication, major version upgrades, etc. We'll run Fly's managed Postgres, which means that we do all that for you, and you can concentrate on building.

The managed service is built with the Fly extension API (also used by Fly Redis).

Testers can launch a Postgres database using the fly extensions command:

Once the service is stable, it will be swapped for the postgres namespace:

With Fly Postgres, the database is deployed within Fly infrastructure leading to a much lower latency for data heavy applications.

Under the hood#

Let's dig into the implementation.

Working with Fly machines#

Fly Postgres is built on top of Fly machines. Machines are light-weight Firecracker VMs. The Machines API offers substantial control over an application's lifecycle. They can be suspended during inactivity and resumed within a couple of seconds whenever a new request arrives.

We built fly-admin, a Typescript wrapper to simplify our interaction with the Fly API. Supabase bundles a few extra services into Postgres, so we prepared a single Docker image which we can pass to the Fly Machines API. Our current build process outputs an AMI for AWS using Packer. We re-use parts of that pipeline to build an All In One Image. This image has all the services to run a Supabase project within a single Docker container.

Move to multi-cloud#

With this launch, Supabase is officially multi-cloud. We deliberately avoided using AWS's managed services when building Supabase to simplify our multi-cloud transition. These transitions are never simple - even the base primitives offered between cloud providers can vary significantly.

For example, Fly Machines offer a simple method for suspending a VM when it's not in use, transparently resuming it within seconds. This simplifies the process of pausing inactive databases. There is no direct primitive on AWS to achieve this.

On the other hand, we had to work around a few AWS primitives that Fly doesn't provide. Fly machines don't have network-attached storage, so we treat any data in Fly volumes as ephemeral. We run physical backups for all projects running on Fly using WAL-G. Database changes are continuously streamed to S3. When there is a host or volume corruption, we restore the project to a new Fly host using the latest data in S3.

To capture host issues on AWS, we listen to AWS Health events. For Fly, we send the Machine logs to Logflare using the fly-log-shipper.

In addition to publishing images in AWS's container registry, we publish the All In One image to Fly's Docker registry. This improved the reliability and performance of project launches on Fly.

Building the Fly extension#

Fly has an excellent approach for extending their platform. We added a few routes to our API to provision users and projects and we were on our way.

Fly users can access the Supabase dashboard using their existing Fly credentials. The Supabase API initiates an OAuth flow with Fly to authenticate the user. Our Auth team created a Fly OAuth provider to make the integration with our API easier.

Challenges#

We're still working through a few challenges with the Fly team.

Support for Network Restrictions#

The network restrictions feature relies on the container receiving the correct IP of the client connecting to it. With our current setup, the container sees the Fly proxy IP instead. Connections run through the Fly proxy, which exposes the Proxy protocol. Postgres can't use this information directly, but we're looking at making Supavisor proxy-protocol aware.

Backups within Fly#

Fly projects are backed up to AWS S3 as Fly doesn't provide managed Blob storage (yet). This incurs inter-cloud bandwidth fees. Luckily, Fly are working on Blob Storage, watch this space.

Getting started#

Sign up for the preview here, wait till we allowlist your org, and get started with the Quickstart in our docs.

Fly organizations will get one free project. We're still working through some of the finer details on billing, but the pricing will remain relatively unchanged from our current pricing.