Phoenix with Managed Postgres Guide

Fresh Produce
,
1

We’ve published a new guide to make it easier for folks running Phoenix with Fly.io’s Managed Postgres (MPG). It’s focused on the key changes developers need to make when connecting Phoenix to MPG, helping you skip the usual gotchas and get to a working production setup faster.

We’ve also updated the MPG docs navigation to include a dedicated “Guides and Examples” section, making it easier to find framework-specific content like this.

If you’ve worked with Phoenix and Ecto, the basics won’t surprise you. These Managed Postgres adjustments are new, and they’re easy to miss if you’re not looking for them:

  • Connection pooling: MPG uses PgBouncer. Phoenix/Ecto requires Transaction mode, along with prepare: :unnamed.

  • Migrations: PgBouncer’s transaction mode can’t handle advisory locks, so migrations need to run against the direct database URL.

  • Oban jobs: LISTEN/NOTIFY isn’t supported behind PgBouncer. The guide walks through using alternative notifiers (PG, Phoenix PubSub) or a direct connection if you need Postgres LISTEN/NOTIFY.

  • Troubleshooting: A checklist of common errors and fixes, so you can quickly spot misconfigurations.

Check it out here: Phoenix with Managed Postgres

Whether you’re setting up a new Phoenix project or updating an existing app, this guide should save you time and help you avoid the sharp edges we see most often.

5 Likes
3

This only applies if you use the PgBouncer urls (postgresql://...@pgbouncer.<cluster>.flympg.net/fly-db)?

It’s possible to use direct, “normal” connection (postgresql://...@direct.<cluster>.flympg.net/fly-db) without the need for any changes?

4

@kaelynH What are the disadvantages of running Ecto/Oban against direct connection instead of pgbouncer?

1 Like
5

@teamon I was having the same questions and I think its as easy as: you will be running out of connections quicker.

I am migrating over some more DBs to our MPG instance and using direct connections because of easier setup (no changes from previous provider) and we are using Oban on most apps. It seems like between all of the instances of the apps and the various queues set up for Oban for the apps, the available connections is used very quickly on the plan we are currently using. The next plan is quite a jump up in price. I can see why you would use PgBouncer to save on the connections, but it makes the app config more complicated.

I could change to one of the other notifier adapters for Oban so I would not require a direct connection but do not have any information on if there are any cons related to the others vs using LISTEN/NOTIFY.