What is your Phoenix config for PostgreSQL on Supabase?

Hi all,

I spent quite a few hours now trying to figure out how to connect a vanilla Phoenix app running on Fly.io to Supabase but I couldn’t make it work on IPV6.

When creating the Fly.io app, a file (/rel/env.sh.eex) gets created with the following configuration:

#!/bin/sh

# configure node for distributed erlang with IPV6 support
export ERL_AFLAGS="-proto_dist inet6_tcp"
export ECTO_IPV6="true"
export DNS_CLUSTER_QUERY="${FLY_APP_NAME}.internal"
export RELEASE_DISTRIBUTION="name"
export RELEASE_NODE="${FLY_APP_NAME}-${FLY_IMAGE_REF##*-}@${FLY_PRIVATE_IP}"

Then my connection string is configured with a secret in Fly.io:

fly secrets set DATABASE_URL=postgres://...

If I use the default config, then I get the following error connecting with session mode or transaction mode:

17:56:30.334 [error] Postgrex.Protocol (#PID<0.167.0>) failed to connect: ** (DBConnection.ConnectionError) tcp connect (aws-0-us-east-1.pooler.supabase.com:6543): non-existing domain - :nxdomain

Now, if I comment out the IPV6 config line, it works.

#export ECTO_IPV6="true"

I was wondering if any of you got it working under IPV6. It seems today it is supported by both, Fly.io and Supabase but I can’t figure out how to make it work.

How do you set up your database connection from Fly to Supabase?

1 Like

I hit this recently as well when Supabase suddenly dropped IPv4 support.

socket_options: [:inet6] also didn’t work for me- no connection could be made.

this issue suggests that IPv6 support may actually just work out of the box.

My app works with just updating the database URL and not changing any other field. It seems my app takes longer to connect via the IPv6 address, so I had a number of errors with a Fly app that had min machines set to 0.

btw you shouldn’t need to use the pooler url (...pooler.supabase.com...) if you’re on Fly (unless you have lots of nodes and need lots of db connections).

Fly and your db speak IPv6 so you should be able to connect directly.

@chasers I just recently played around with a fresh project (phoenix 1.7.11, elixir 1.16.1/OTP26) and created a vanilla project on Fly. I created a Fly postgres instance for it as well, it got connected, great stuff.

I then proceeded to go with the managed postgres option after reading some docs on Fly and wanted to try out supabase (first time, wanted to try it since you all released that open source elixir project :heart: ). My intent was to create a vanilla project on supabase, get the DATABASE_URL, connect, deploy the fly app and watch things succeed. Much like @rump13 , I get nxdomains and the app won’t even run migrations (I have none (fresh project as I mentioned).

I’m sharing this because you mentioned that folks didn’t need to use that ...pooler... option in the DATABASE_URL. I just wanted to share that this is what folks are seeing (I hope this is helpful, maybe unexpected - if not, please ignore :slight_smile: ). All folks (including me) are doing is copy pasting the URL, this is why this is getting used.

This kinda feels like it could be on Fly’s end though, or very likely me somehow :slight_smile:

Thanks for the write up! Very helpful!

Well you should be able to use the pooler with Fly so we’ll have to look into this :nxdomain issue.

We show people the pooler URL first because typically you’d create a db and likely sign into it from your house. And in general right now IPv4 works from more places so we want to default to that (of course it isn’t working from Fly atm). And also, generally, more folks need a pooler than not.

Note: if you try to connect without the pooler, Supabase shows a big angry warning:

Edit: Supabase informed me that this warning is really just for the previous IPv4 URL, which has already gone away. The direct access URL will still work.