Early look: PostgreSQL on Fly. We want your opinions.

We’re launching PostgreSQL on Fly soon. We’d like some feedback, and volunteers to test it out. Here’s what we’re planning:

Launch high availability PostgreSQL clusters

These will be two instance PostgreSQL clusters (using stolon, if you’re a DB nerd). The smallest option will be a cluster on 2x shared-cpu-1x VMs with 256MB of RAM and 10GB of disk space. Total cost, about $7.50 per month. You can scale these like any Fly app, all the way up to 8 CPUs, 64GB RAM, 500GB disks.

You will have admin rights to these clusters, so you can add as many PostgreSQL DBs and users as you want, share them between apps, etc.

Notably, we will not have free databases because multitenant, free PostgresSQL clusters are an atrocity.

We also will not offer single instance PostgreSQL databases. This will save both us and you headaches.

DB management

You’ll notice that prices are only the cost of the underlying VMs. This is on purpose, so you can buy cheap DB clusters and use them for side projects, development, etc.

They will include built in health checks, metrics, and alerts. You’ll be able to wire these up to PagerDuty and get paged when something does go awry with the cluster (like you fill up the disk).

Later on, you’ll be able to bundle alerts into any application. AND you’ll be able to pay $$ to have us (or community members) respond to alerts.


What we’re doing is a little different than most self service PostgreSQL products. Does this sound useful to you all? And do any of you want to try it out in the next few weeks?


:heart_eyes: how exciting! Looking forward to giving this a shot at Draftbit :smile:


Fantastic timing - I’m working on migrating the open source Core distribution of Prefect (the latest hotness in dataflow automation platforms) to run on Fly and integrate along with some other goodies. Swapping the Hasura postgres node that is backing the workflow scheduler with something that can really scale is a game-changer for enabling colocation of data ingestion and processing on the edge.

IMO this coupled with the templated Minio, NATS, and the very new KeyDB launch templates and I’m seeing a very compelling story for a zero-ops turnkey Unified@Edge Data Infrastructure.


People are going to think we bribed you to say all that because it’s 100% on the nose. :smiley:

1 Like

Now this is cool!

What we’re doing is a little different than most self service PostgreSQL products.

How is this different from something like Google Cloud SQL? Here you own it of course, but it seems like they’re both Postgres with management made easier.

Secondly, why not use a distributed SQL database like Cockroach? It seems like it would fit really well with the competitive advantages of fly.

1 Like

Great timing. I resorted to deploying an app on Heroku yesterday because I didn’t want to manage Postgres myself on Fly.

Where do we sign up? :grinning_face_with_smiling_eyes:

This feels like maybe the last shoe to drop. I’m convinced that a lot of people who are getting sucked into serverless basically just want something less black-box-y than Heroku, cheaper, and easier to push out to the edge. For me at least, I want to be able to put up a simple Rails/Redis/PostgreSQL stack and know that if traffic starts shooting up I’m not suddenly caught flat-footed. Up until now, Heroku was the obvious choice (and maybe Render lately as a #2 choice). But honestly, I’d much rather run containers on the edge and just spin up more containers if/when load demands it. I’m super excited about this and can’t wait to try it out!


I second this question. I saw in your HN thread you mentioned Cockroach a few times. Is the familiarity for users at play in choosing a db? (Though of course, having Postgres at first doesn’t mean Cockroach will never come)

What we’re doing is similar to Google Cloud SQL (and AWS RDS) because you’re getting Postgres, but delivered differently. On Fly, postgres will just be another app. It’ll be the first kind of app to use new health check + alert features, and it’ll be something you launch from our configuration (or fork and change if you want). flyctl will work like you’re used to. In fact, you’ll be able to add geo replicas with flyctl just like you add regions for your other apps.

Which brings me to Cockroach. Cockroach is great, but it’s not quite as drop-in of a Postgres alternative as we wanted. Our goal is to get a DB option that people can use for their normal full stack frameworks, figure out how to do it across regions (hello geo replicas), and then see what’s next.

Also, Timescale was a big factor. You’ll be able to run Timescale in your Fly Postgres. Having time series in a ready to go DB is pretty swanky.


How do you all want to be notified of alerts? We’re thinking:

  • PagerDuty
  • Slack
  • Webhook

That seems like 90% of what people will need, and then webhooks to make anything else possible with a little work.

1 Like

As long as there’s a webhook, it’ll be fine :slight_smile:

If you’re still looking for beta testers, I’m up for it!

Any thoughts on how upgrades are going to work? Since users could still manage the instances themselves are they expected to self-serve, or will there likely be hand-holding here as well?

1 Like

Minor release upgrades will just be a quick flyctl deploy -i <new-version> away, and will be graceful. We haven’t decided how to do major upgrades yet, but the plan is to automate that as well. Major releases will probably require a preboot option for deploys apps can run some logic for an upgrade process.

1 Like


An example of HA using Hasura + PostreSQL would be really great!

Instant graphql API with a great Database.