PGBouncer and IPv4 Deprecation

[chasers]

Updates

• The deadline for the migration has been updated to 26th January 2024.
• You can now purchase a IPv4 address from the add-ons page here if you want to keep using your IPv4 address. More info here.

---

Moving to IPV6 for Database Connection Strings

With IPv4 addresses becoming increasingly scarce and cloud providers starting to charge for it, we won’t be assigning IPv4 addresses to Supabase projects from January 15th 2024. db.projectref.supabase.co will start resolving to a IPv6 address instead. If you plan on connecting to your database directly, you must ensure that your network can communicate over IPv6. Supavisor will continue to return IPv4 addresses, so you can update your applications to connect to Supavisor instead.

There will be a few minutes of downtime during this migration.

Switching to Supavisor

We recently announced Supavisor, our new connection pooler. Supavisor is a direct replacement for PgBouncer. Using our own pooler is going to let us do things like load balancing queries across read replicas, query results caching, and a lot more.

Supavisor is now enabled for all projects created on or after Wednesday September 27th 2023. All existing projects will have Supavisor enabled by October 15th 2023.

Supavisor does not currently support Network Restrictions. Network restrictions support will be enabled from 24th January 2024. If you are blocked on the migration because of this, please reach out to support and we will extend the deadline for your project.

You don’t need to change anything in your application, except for the URL. The pooler connection string is available in the database settings in your dashboard.

For example, if you use PgBouncer to connect:

import { drizzle } from 'drizzle-orm/postgres-js'
import postgres from 'postgres'
import { users } from './schema'

// probably an env var
const connectionString = 'postgres://user:[YOUR-PASSWORD]@db.[YOUR-PROJECT-ID].supabase.co:6543/postgres'
const client = postgres(connectionString)
const db = drizzle(client);

const allUsers = await db.select().from(users);

you just need to update the connection string to:

import { drizzle } from 'drizzle-orm/postgres-js'
import postgres from 'postgres'
import { users } from './schema'

// probably an env var, get the exact connection string from the database settings page
const connectionString = 'postgres://[db-user]:[db-password]@aws-0-[aws-region].pooler.supabase.com:6543/[db-name]?options=reference%3D[project-ref]'
const client = postgres(connectionString)
const db = drizzle(client);

const allUsers = await db.select().from(users);

PgBouncer and IPv4 deprecation timeline

PgBouncer will be available to use along side Supavisor until January 31st 2024.

The full timeline is:

• 27 September 2023: Supavisor is available for all new projects.
• 15 October 2023: Supavisor will be available for all projects, including existing projects. We will notify you via email when it is enabled for your project. PgBouncer is officially deprecated after this date.
• 15th January 2024 26th January 2024: You will need to start using Supavisor before then.
• 29th January 2024: Your Supabase database domain (db.projectref.supabase.co) will start resolving to IPv6 addresses. PgBouncer will be removed. Projects will be migrated over starting this day. No changes are required if your network supports communicating via IPv6. If it doesn't, update your applications to use Supavisor which will continue to return IPv4 addresses.

You will receive deprecation notices throughout November, December, and January.

FAQs

Do I need to change anything if I use supabase-js?

For projects which only use the database REST API provided by PostgREST (via supabase-js) there is no action needed.

Will Supabase APIs also be switched to IPv6?

projectref.supabase.co will continue to return IPv4 addresses. Only the database domain db.projectref.supabase.co will return a IPv6 address.

How do I know if my network supports IPv6?

Check if you are able to request your IPv6 address via curl -6 https://ifconfig.co/ip

What do I do if I have issues switching?

If you have issues with Supavisor please contact support!

Can I pay for a IPv4 address to directly access the database via IPv4 instead of going through Supavisor?

You can purchase the IPv4 addon for 4$/project in the project add-on page here. PGBouncer will still be removed for users with the IPv4 add-on.

Can I use PgBouncer and Supavisor at the same time?

While we are providing the ability to use PgBouncer or Supavisor during this migration you cannot use both at the same time. With the default configuration using both will exhaust your database connections because they both will try and spin up a connection pool.

The solution is to temporarily increase your databases connection limit with a custom Postgres config to accommodate both connection pools.

supabase --experimental --project-ref <project-ref> postgres-config update --config max_connections=120

How can I tell if I need to make a change?

If the URL you use to connect to your Supabase Database looks like this, you're using the API, and no changes are necessary:

https://[YOUR-PROJECT-ID].supabase.co

If the URL you use to connect looks like either of these options, you're already using Supavisor, and no further changes are necessary:

postgres://[db-user]:[db-password]@aws-0-[aws-region].pooler.supabase.com:6543/[db-name]?options=reference%3D[project-ref] or postgres://[db-user].[project-ref]:[db-password]@aws-0-[aws-region].pooler.supabase.com:6543/[db-name]

If the URL you use to connect looks like this, you are using pgBouncer, and you need to upgrade (notice port 6543):

postgresql://[db-user]:[db-password]@db.[project-ref]supabase.co:6543/[db-name]

If the URL you use to connect looks like this, you are connecting directly, and will either need to be able to connect via IPv6, OR you will need to update to the Supavisor URL:

postgresql://[db-user]:[db-password]@db.[project-ref].supabase.co:5432/[db-name]

How will I know if my project has been migrated to IPv6?

In the database settings page, the label when connection pooling is disabled, reads Will resolve to IPv6 if your project has not been migrated. If your project has been migrated to IPv6, it reads `Resolves to IPv6'.

What are the errors that I might see when connecting to the database if my network doesn't support IPv6?

The error thrown will depend on how you are connecting to the database. Here are some examples of error messages you might see

• (dial tcp [2001:db8:3333:4444:5555:6666:7777:8888]:5432: connect: no route to host)
• connect to db.example.supabase.co (2001:db8:3333:4444:5555:6666:7777:8888) port 5432 (tcp) failed: Network is unreachable
• could not translate host name "db.example.supabase.co" to address: nodename nor servname provided, or not known
• ENETUNREACH 2001:db8:3333:4444:5555:6666:7777:8888
• Error: P1001: Can't reach database server at db.example.supabase.co:5432
• (2001:db8:3333:4444:5555:6666:7777:8888), port 5432 failed: could not create socket: Address family not supported by protocol

Note that these errors may manifest in cases other than your client network not supporting IPv6, but if you run into these errors after your project was migrated, it is likely that it is due to IPv6 support.

How will I know if PgBouncer has been removed from my project?

The database settings page does not show PgBouncer connection settings. If you see a warning label called PgBouncer pending removal, it means that PgBouncer has not been removed from your project. If you see no such label, PgBouncer has already been removed from your project.

Does Supavisor support prepared statements?

Prepared statements are supported with session mode. You can change your pool mode to session in your dashboard.

You can also use a session mode pool with your Supavisor pooler url and port 5432 (vs 6543). If you need to run something using prepared statements while your production application uses transaction mode you can use this port to do that.

Initial support for prepared statements with transaction mode landed but some bugs were found and should be fixed shortly.

What do I do if I am using Prisma?

If you are using Prisma, please check out our updated Prisma Guide for instructions on how to configure your connections for both querying and migrations.

How do I update my Vercel Supabase integration?

The environment variables POSTGRES_URL and POSTGRES_PRISMA_URL point to Supavisor and POSTGRES_URL_NON_POOLING points to Supavisor in session mode. Redeploy your Vercel application to pick up the latest environment variables. This is required since Vercel does not support IPv6.

How do I use direct database connections in my Vercel application instead of using the connection pooler?

Enable the IPv4 add-on. Set the direct connection url as a environment variable not managed by the Supabase integration. You can now use the environment variable in your application.

Do I need to make any changes if I am using the CLI?

If you are using a version before 1.136.3, please upgrade to a later version of the CLI and run supabase link. If you haven’t run supabase link since 1st January 2024, please run it again after upgrading. This will enable the CLI to communicate to the database from IPv4 only environments because the communication happens via Supavisor. This change is required if you are using from the CLI from an environment without IPv6 support, like Github actions or possibly from your home network.

Special Considerations for .NET users using npgSQL

You will need to add Pooling=false to your Supavisor connection string.

Why can't I upgrade my database version anymore?

We are in the midst of transitioning all projects to IPv6. As part of this process, If your project is still being assigned an IPv4 address then pg_upgrade will be temporarily disabled for your project until the transition is completed.

[paanjoe]

@chasers

If I go into my connection strings settings in Supabase, all I see is this connection string:

postgres://postgres:[YOUR-PASSWORD]@db.[DATABASE-ID].supabase.co:6543/postgres

I saw the connection strings would be including the region, how do I find this information?

[chasers]

This means your project is not flipped to Supavisor yet. If you want you can contact support and we can flip it for you.

[paanjoe]

Nice! Then I'll inform my lead on this matter because I don't have enough rights to see this actions. Thanks!

[markibanez]

I tried switching to supavisor via this url postgres://postgres.lxrbpmzjqdsvvgvwvgep:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:6543/postgres but our app could not connect to the database. Our app uses NextJS and Prisma if that matters.

[saadbahir]

I have the same problem too and i am only using supavisor

[joshpachner]

The issue for me was an underlining config problem. Apparently my connection limit was set to "30" instead of 200. Once Supabase support changed the config on their side, the problem went away for us

[jakeleventhal]

I am using Next.js and Prisma with Vercel functions. If I run one route quickly 100 times, I get the max clients error. Yet in Supabase it says I am using 25/60. Very strange behavior...

[nvinayvarma189]

Hey @chasers we are facing the issue since we have migrated to this connection URL

URL = f"postgresql://{user}.{supabase_project_ref_id}:{password}@aws-0-ap-south-1.pooler.supabase.com:{port}/{db_name}"

In our dashboard, we see that only 38/90 connections are being used by the roles managed by supabase. An additional ~20 connections are being used by the user profile we have created for our application.

But we observe a lot of the following errors in the logs of our app:

sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) connection to server at "aws-0-ap-south-1.pooler.supabase.com" (<ip_address>), port 5432 failed: FATAL:  Max client connections reached.

cc: @zcesur @jakeleventhal @AurelienGasser did any of you get to solve this issue?

Screenshots

[dexlords]

that works, thanks

[chasers]

Do you have the template for .NET connection strings?

@paanjoe can you let me know which client exactly you're using?

[paanjoe]

Npgsql (https://www.connectionstrings.com/npgsql/)

My project didn't use supabase-sharp

[chasers]

Okay thanks!

If you can reproduce in a repo you can share with me that would be extremely helpful!

[enzi]

any update on this? having the same problem with npgsql
solution here: https://github.com/orgs/supabase/discussions/17817#discussioncomment-8159366

[nzf210]

hi have done update my string connection like this, 'postgres://postgres.idxxxxxxx:MyPass@aws-0-ap-southeast-1.pooler.supabase.com:6543/stg_django
but this have problem database connect by default to postgresql i can't define manually i wan to connect to db like stg_django

[chasers]

Confirmed this is a bug!

I have created this issue. Should be fixed shortly.

[FourLeafTec]

@chasers
Has this feature taken effect on supabase cloud?
I switched to the Supavisor connection string in my cloud database and found that it still connected to the default db.

[inian]

Hi, we are aware of this issue and working on a fix now. Please track it here

[aldoyh]

Migrated without a glitch! Bravo Supabase 👏🏼

[daniel-xyz]

I'd like to get Supavisor working in my local dev environment without a manual setup. Any plans to include it in the default docker-compose.yml and is there a rough ETA? I'd like to make the switch from supabase-js to websockets connections as soon as everything is smoothed out.

[chasers]

You can follow this one here. Once that's done it should be in docker compose shortly after!

[TomasHubelbauer]

How can I tell if my project is still using PgBouncer or already using Supavisor via the Dashboard? I looked through the project settings but I do not see any explicit indication. I would expect to see it in Project Settings > General and Project Settings > Infrastructure.

[chasers]

In the pooler URL you will see .pooler. if your project has Supavisor enabled.

If it does not ping support and they will make sure it's enabled.

[TomasHubelbauer]

Is there a plan to introduce a more obvious UI element into the Dashboard to make this clearer? This works but it feels like relying on a technical implementation detail rather than a proper way to display this type of information.

[inian]

Hi, we have updated the database settings page to make this clearer.

[sshah98]

Adding pgBouncer worked locally with our setup (Next.js + Prisma) 👍 however, when deploying via vercel, running into this issue: db error: ERROR: prepared statement "s0" does not exist

All I did was simply change the existing database URL to the updated Supavisor string. Any ideas?

[leogilmour]

We previously used our pg bouncer connection with migrations (because we run migrations on build step) and only occasionally had an issue
Whereas this new connection string has an issue without fail. Switched back to old pg bouncer 6543 string and it's working again.
I know you're not supposed to run migrations on pooler connections but they have mostly been fine for us. This seems to work differently...

[jsonkcli]

I get Error:P1001: Can't reach database server ataws-0-us-east-1.pooler.supabase.com:5432``

when using the direct using for my migration. Also using prisma

[jsonkcli]

And Error: Schema engine error: db error: ERROR: prepared statement "s0" does not exist

with the pooler address on port 6543

[chasers]

I get Error:P1001: Can't reach database server ataws-0-us-east-1.pooler.supabase.com:5432

@jsonkcli your direct connection is like db.REF.supabase.co:5432

And you need to not use prepared statements. How to do that exactly depends on your client/orm.

[Danziger]

You are probably missing the directUrl field in your schema.prisma.

See https://github.com/orgs/supabase/discussions/17817#discussioncomment-8148100.

[vincentjflorio]

Right now in our Next.js app we are using a custom domain in the connection string through environment variable; if we don't, the social auth has the sketchy-looking normal name, and the URLs in the Network tab for requests don't reflect it.

If switching to Supavisor involves replacing the old connection string with a new one, and we're not currently using the old one how does one reconcile that? To have the new abilities but still show the custom domain?

Also if the live site is using the old string but we wanted to test Supavisor locally, does that count as "using them both together" and needing the temporary config adjustment, because the database doesn't care how the requests get to it, just that they did?

[darora]

@vincentjflorio the connection string you use to connect to Postgres (/pgbouncer/supavisor) is unrelated to the URL you use for social auth. Custom domain support (for auth, and other HTTP APIs) is documented at https://supabase.com/docs/guides/platform/custom-domains .

Are you opening raw Postgres connections from your frontend?

During the transition period, you should be able to use Supavisor and pgbouncer at the same time if needed, in order to facilitate your testing and transition.

[vincentjflorio]

@darora Ah, no, nothing raw from the front end. My question misunderstood the concerns surrounding this section: https://supabase.com/docs/guides/platform/custom-domains#activate-your-domain

Previously the social auth used to display the default Supabase database domain, until we activated a custom domain. Because our createClient previously referenced the same domain name, and because the default there happen to look very similar to the non-Supavisor connection string, that somehow a the new connection string format meant that the client URL had to change accordingly, or be accommodated in someway.

I see now that I missed the Q&A at the very opening of this thread where PostgREST via supabase-js makes my entire question moot.

I appreciate the quick response looking into that nuance and clarifying it for me. It sounds like since the project dashboard says it's live, and the new connection string is available, that we are officially 'moved over' on our site without having to do anything.

[kibitheM]

Can I use supavisor in my android studio project...also does it mean that now all my database queries will be cached?

[chasers]

No you don't want to use a direct or pooled connection to your database on the client (web, or app) because people could pull your database credentials and do arbitrary queries with it.

[akinwol]

I am having issues with supavisor x prisma on vercel when running prisma transactions. This is only happening with supabase since this change. I switched to other providers as a test and the issue does not occur.

I am getting ready to launch so this is a quite frustrating and haven't been able to figure out the issue all week.

I have created an issue for this but going to try here hopefully someone can help. I've tried changing the timeout/maxWait time setting on prisma and nothing changes. There seems to be a connection issue that

The Problem
For some reason I periodically get PrismaClientKnownRequestError: Server has closed the connection. error on my api routes.
In my supabase database logs I see unexpected EOF on client connection with an open transaction. Never seen either of these errors before so not sure what's going on.

This tends to only happen when I run prisma transactions. Doesn't happen with other reads/writes. It happens about 20% of the time which is a lot. I can't figure out why it's happening. I even increased the connection timeout to 10 seconds.

After a few minutes of inactivity it tends to also happen.

I switch to a different db using pgbouncer and it doesn't happen at all. Or if I connect to Supabase db directly it doesn't happen.
This seems like it's only happening with supavisor connection pool.

To test I am navigating between 2 screens that are fetching data from an api using prisma transaction. 20% of the time I will get this error.

Since Supabase has moved away from Pgbouncer to supavisor. Is there a different configuration we need when working with Prisma ? Particularly when running Prisma transactions.

Here is a simple code sample that triggers this error. In this example, I am just checking if a authenticated user has been created in my db. If not I create the user and update the user in my auth provider (clerk).

      const user = await tx.userProfiles.upsert({
        where: {
          clerkId: ctx.user.authId,
        },
        create: {
          avatarUrl: ctx.user.avatarUrl,
          email: ctx.user.email,
          fullName: ctx.user.fullName,
          clerkId: ctx.user.authId,
          id: ctx.user.externalId || undefined,
        },
        update: {},
        select: {
          id: true,
          avatarUrl: true,
          email: true,
          fullName: true,
          clerkId: true,
        },
      });
      if (!ctx.user.externalId) {
        await clerk.users.updateUser(ctx.user.authId, {
          externalId: user.id,
        });
      }

      return user;
    });

Screenshots

Here is a copy of my logs in supabase

Here is the log metadata

{
  "file": null,
  "host": "db-xxxxxxxxxxxxx",
  "metadata": [],
  "parsed": [
    {
      "application_name": "supavisor",
      "backend_type": "client backend",
      "command_tag": "idle in transaction",
      "connection_from": "10.109.6.254:37068",
      "context": null,
      "database_name": "postgres",
      "detail": null,
      "error_severity": "LOG",
      "hint": null,
      "internal_query": null,
      "internal_query_pos": null,
      "leader_pid": null,
      "location": null,
      "process_id": 63803,
      "query": null,
      "query_id": 0,
      "query_pos": null,
      "session_id": "65313f29.f93b",
      "session_line_num": 4,
      "session_start_time": "2023-10-19 14:37:29 UTC",
      "sql_state_code": "08006",
      "timestamp": "2023-10-19 14:40:20.121 UTC",
      "transaction_id": 0,
      "user_name": "postgres",
      "virtual_transaction_id": "20/265"
    }
  ],
  "parsed_from": null,
  "project": null,
  "source_type": null
}

In sentry here is what I see when I log the end of the function.

[akinwol]

@chasers is there something that can be done in the meantime ? I don't see the old connection string. Can we still use pgbouncer while this is being looked at?

[chasers]

Yes you can still use pgbouncer. That connection string should be simply your direct connection but use port 6543.

We've identified the issue and this should be on prod in the next day or so.

[devidw]

After switching to supervisor, we are also seeing periodic prisma errors Server has closed the connection. in our Sentry. We never had them before with the direct db URLs. We are not seeing any errors in the dashboard Logs > Postgres. We are assuming a direct relation between those errors and switching to Supervisor. @chasers

[devidw]

https://discord.com/channels/839993398554656828/1193972061857652867

[2pmflow]

Hey @akinwol / @chasers / @devidw - did any of you guys hit resolution here? We are getting Server has closed the connection with our prisma/Vercel/supabase setup.

Edit: it looks like this was fixed for @akinwol - but others are still getting "Server has closed the connection" for various reasons.

[dwcarr]

Currently, i can only access my database if i use the new connection string + ?pgbouncer=true . Is this the intended operation? t I am using per the above (it has the .pooler in it).

[xBurnsed]

@chasers Just tried with Session mode with both ports 5432 and 6543 and I am getting prepared statements issues. It's only working if I add pgbouncer=true

[iarwain88]

i'm trying with ?prepareThreshold=0 instead of pgbouncer=true and it looks fine. Before, without any parameters I was having statements issue, too.

[xBurnsed]

Where did you get the ?prepareThreshold=0 from? Any documentation link for reference? What does it do?

[iarwain88]

i was looking for the error and I found out this result: https://stackoverflow.com/questions/7611926/postgres-error-prepared-statement-s-1-already-exists
but also here: digitalocean/databases#17
it looks like the parameter disables the prepared statements , but I'm not an expert about it. Hope we can have a better support from supabase..

[inian]

We have updated the Prisma guide and have confirmed migrations and data access work with it. If you were facing issues before, can you please try with the instructions in the guide? Thanks!

[rkistner]

On the IPv4 deprecation:

1. Is there a way to test the IPv6 setup on a separate project before the 14th of Jan, to make sure there aren't any issues when the migration happens?
2. What will happen to the current IPv4 network restrictions? Will this be replaced by IPv6 network restrictions?

We're connecting to many separate Supabase instances for logical replication, so can't go through a connection pooler.

[darora]

Re: (1) Not at the moment, but it will be possible at some point over the next month or so. We'll make a public announcement and also mention it here when that happens.
Re: (2) The work for supporting IPv6 restrictions has not been planned yet, but we'll be scoping it out over the coming weeks.

[inian]

IPv4 and IPv6 network restrictions are supported - https://supabase.com/docs/guides/platform/network-restrictions

[2pmflow]

I was hitting unexpected Max client connections reached with a prisma + supavisor setup, even with relatively low traffic on our webapp relative to our add-on.

We also ran
"pgbench -c 200 -j 3 -T 30 -h -U -d postgres -M extended"
against the supavisor pooler, 200 clients, 3 threads, 30 seconds. it failed with FATAL: remaining connection slots are reserved for non-replication superuser connections

I'm not sure why this failed given our add-on. Additionally, if the connections are all being used at a specific point in time, shouldn't requests be waiting for one to open up, instead of hitting errors from connections being maxed out? Our users were hitting immediate errors instead of ones waiting for a timeout. Without an ability to see supavisor's configs and timeouts I'm not sure what I should be expecting.

I filed a support ticket yesterday but it seems to have stalled in the system after it was forwarded to the pooling team over a day ago.

Appreciate any help, thanks.

[2pmflow]

Thanks! To clarify, I believe we were hitting both Max client connections reached (from production usage) and FATAL: remaining connection slots are reserved for non-replication superuser connections (from pgbench) when I wasn't running both pools at the same time, only supavisor, hence still confused. Will try to investigate more here.

---

this is how it should work until you hit your Supavisor client connection limit which is the same as it was with PgBouncer

Is client connection here in reference to max_client_conn on pgbouncer? My understanding is that on pgbouncer, if max_client_conn is exceeded, requests wait around for max query_wait_timeout before erroring. Whereas with supavisor, when my client connection limit was hit, I seemed to get Max client connections reached instead of having my requests queue up. What's the query_wait_timeout equivalent for supavisor?

---

Also wanted to better understand what these mean from an add-on package

Specifically what is a "pooler connection" in this context? Is it supavisor's equivalent of max_client_conn on pgbouncer config- max client connections to the pgbouncer process?

Similarly, what is a "direct connection" in this context? Is it in reference to max number of incoming connections to the postgres db (similar to max_connections in postgres config)?

[chasers]

Actually ... root cause here looks like your PgBouncer config was set higher than usual for some reason and when your project was enabled it Supavisor those settings did not get in there correctly. That has been fixed!

[2pmflow]

Thanks @chasers - left some more additional questions for you in the customer support ticket

[joshpachner]

@chasers is there a way for me to check if my supavisor settings are correct? i feel like im in the same boat of @2pmflow of getting max client connections errors even at an extreme low volume of requests. (Im talking 1 user, make single requests at a time to our supabase via the supavisor connection string)

[Nicolasvegam]

same here!

[JeroenvdBurg]

We are using PowerApps to connect to the database (with the Postgress cloud connector) and with PGbouncer this was working fine. With the new supavisor connection pooler it has trouble connecting to it. It lists the tables but when fetching data it is giving errors. Direct connection is working but that will run out of connections pretty soon.

also getting remaining connection slots are reserved for non-replication superuser connections error message in the log of the pooler. I have upgraded the amount of connections via the postgress config to 120.

Maybe anyone has a idea or got this working?

I created a support ticket > ID: 2110385566

[chasers]

That ticket doesn't seem to have anything to do with PowerApps.

Is this still an issue?

[JeroenvdBurg]

yes, for now I switched to direct connection, which works. But can't connect via the the new connection pooler.

[w3b6x9]

@JeroenvdBurg i pinged you on the ticket but wanted to try you here as well. did you ever get it working with supavisor or are you still on direct conns?

[amitav13]

Is it ever advisable to use transaction mode on a long running server? We make a lot of parallel requests, use Prisma. Is there a strict downside to this?

[Nicolasvegam]

still getting max client connection errror!!!

[ThingEngineer]

The Time Has Come... for IPv6

Running Supabase 1.142.2, I can relink on an IPv6 network, stop/start supabase local, and perform any CLI action. But once I switch back to an IPv4 only network, I cannot perform any CLI action that attempts to connect to the remote db (supabase migration list, supabase db push, etc). It still returns the same error:

failed to connect to `host=db.PROJECT-REF.supabase.co user=postgres database=postgres`: dial error (dial tcp [2600:1f1c:f9:XXXX:XXXX:XXXX:a79:XXXX]:XXXX: connect: no route to host)

I had to break down and finally setup IPv6 on my firewall. I was forced to use my phone's hotspot to push db migrations in the interim since it supported IPv6.

[WillyRamirez]

Did you ever find a solution for this? I can't run supabase link locally because my network provider doesn't support ipv6.

[YugBhanushali]

I had the same issue but found out that the issue was due to the firewall of my network.

[ChuckJonas]

This has broken my github actions and I'm not sure what steps need to be taken.

supabase link --project-ref $SUPABASE_PROJECT_ID
  supabase db push
  shell: /usr/bin/bash -e {0}
  env:
    SUPABASE_ACCESS_TOKEN: ***
    SUPABASE_DB_PASSWORD: ***
    SUPABASE_PROJECT_ID: ***
    SUPABASE_INTERNAL_IMAGE_REGISTRY: ghcr.io
Retrying... db.***.supabase.co 54[3](actions/runs/9160819590/job/25184332815#step:5:3)2
failed to connect to `host=db.***.supabase.co user=postgres database=postgres`: dial error (dial tcp [2600:1f1c:f9:[4](connect: network is unreachable)

Anyone figured this out?

[kmalloy24]

Is anyone else having performance issues after updating their URI connection string? REST requests are taking much longer in my app than before I updated. I've been on the free plan the whole time.

[devshark]

There seems to be a huge delay after changing the IP addresses from the Network Restrictions.

I tried to connect but getting an IP restriction error.

psql -h aws-region.pooler.supabase.com -p 5432 -d postgres -U username

and then I keep getting the same error (obviously the IP addresses are replaced)

psql: error: connection to server at "aws-region.pooler.supabase.com" (52.74.252.201), port 5432 failed: FATAL:  Address not in tenant allow_list: {172, 16, 3, 194}
connection to server at "aws-region.pooler.supabase.com" (52.74.252.201), port 5432 failed: FATAL:  Address not in tenant allow_list: {172, 16, 3, 194}

[devshark]

I have tried removing all IP addresses, and it still fails with the same error.

[joaoaoaoj66]

I have the same problem

[devshark]

It's resolved for me now by the support team

[hunar1312]

hey guys,

I'm using prisma + supabase in my remix.js app and all my configurations and connections are fine and worked smooth until yesterday I started getting this error on deploying migrations:

PrismaClientInitializationError: Error querying the database: FATAL: Tenant or user not found at t (/node_modules/@prisma/client/runtime/library.js:116:2723)
Scheduler and workers registration completed error: Tenant or user not found

does anyone has idea why I'm getting this?

[sidescorp]

Hello,
I am making changes to the connection to update an app that uses a database with supabase,
I'm using .net and npgsql 8.0.2,
the difference is that I have defined several schemas to connect to, before the change, I used "search path =schema_name " to indicate the schema in the connection string, with the change it does not take into account the search path, because it reports the error "relation does not exist",

has the way of connecting to a schema changed?

I can't use [schema].tablename as I would have to change all the queries.
I use the connection string like this: User Id=postgres.[USER];Password=[YOUR-PASSWORD];Server=aws-0-us-east-1.pooler.supabase.com;Port=5432;Database =postgres;search path=schema_name

[ardabeyazoglu]

Is it possible that this change affected fdw connections? I started getting "Connection timed out" errors while querying remote tables although remote server is online and accessible.

[jesse-a-reilly]

Can confirm this - I've been receiving errors querying tables on a foreign Postgres server. After lots of digging, I found that the foreign server wasn't listening for connections over IPV6. The foreign server uses pg_bouncer, and can only listen on a single address/port at a time (either IPV4 or IPV6). For me the solution was to pay the $4 to enable IPV4 on Supabase - once I did that, my FDW connection began working again.

[ardabeyazoglu]

Yes, I did the same to solve the issue.

[belvedereclub]

I have Next.js 13 (app) project running on DigitalOcean App Platform with Prisma.

I followed the instructions in this thread and here: https://supabase.com/partners/integrations/prisma

I updated the env variables from postgresql://postgres:[PASSWORD]@db.[PROJECT].supabase.co:5432/postgres to:

DIRECT_URL: postgres://postgres.[PROJECT]:[PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres?pgbouncer=true&connection_limit=1

DATABASE_URL: postgres://postgres.[PROJECT]:[PASSWORD]@aws-0-us-west-1.pooler.supabase.com:6543/postgres?pgbouncer=true&connection_limit=1

On build I'm getting the error Can't reach database server at db.[PROJECT].supabase.co:5432

What did I do wrong? There's definitely something I missed.

[benaitis]

did you manage to solve this issue?

[belvedereclub]

I recreated my DO project and it started to work. It looks like the problem was on the DO side.

[benaitis]

what is "DO"?

[belvedereclub]

DigitalOcean

[italoiz]

@belvedereclub Did you manage this issue? I'm facing the same issue intermittently, but I'm using Droplets.

[tortechnocom]

IPV6 access is slower than IPV4. 👎

[jacksonblankenship]

I'm getting this error when trying to use a direct connection via the CLI using psql:

could not translate host name "<host>" to address: nodename nor servname provided, or not known

At the same time, I can run this curl -6 https://ifconfig.co/ip without issue, which seems contradictory.

I've also tried connecting via drizzle, which gives this error:

Error: getaddrinfo ENOTFOUND <host>
    at GetAddrInfoReqWrap.onlookupall [as oncomplete] (node:dns:118:26) {
  errno: -3008,
  code: 'ENOTFOUND',
  syscall: 'getaddrinfo',
  hostname: '<host>'
}

Does anybody have any idea what's going on with this?

[w3b6x9]

@jacksonblankenship create a ticket at https://supabase.help and we'll take a look.

[jacksonblankenship]

I corrected the issue by returning to connection pooling (session) and setting idle_timeout: 0.1 in the postgres definition.

import { drizzle } from 'drizzle-orm/postgres-js';
import postgres from 'postgres';

import { env } from '../env';

import * as schema from './schema';

export const conn = postgres(env.DATABASE_URL, {
  idle_timeout: 0.1,
});

export const db = drizzle(conn, { schema });

[gmourasilva]

In the database page I have connection pooling enabled and it is showing "Resolves to IPv4" and "PgBouncer pending removal". My network has no IPv6 support.

Until a few days ago, my database connection is something like postgres://postgres.USERNAME:PASSWORD@aws-0-us-east-1.pooler.supabase.com:6543/postgres and I was able to run pg_dump $DATABASE_URL --clean > db.sql without issues.

The deprecation was supposed to happen on Jan and it only happened now?

Just confirming what is going on. Thanks

[w3b6x9]

@gmourasilva create a ticket at https://supabase.help and we'll take a look.

[YugBhanushali]

Description:
When attempting to connect to the database using Prisma with the correct directURL and database URL configuration, I encounter a connection error but only when using an IPv4-only network. The error message is as follows:

Error: Invalid `prisma.role.findMany()` invocation:
Can't reach database server at `aws-0-ap-south-1.pooler.supabase.com`:`6543`
Please make sure your database server is running at `aws-0-ap-south-1.pooler.supabase.com`:`6543`.

However, when switching to a network that supports both IPv4 and IPv6 (e.g., using my phone's hotspot), the connection is established successfully, and no errors occur.

[autopaybyphone]

[inian]

We aren't changing any pooling modes, there is no breaking change and no action is required on your side.

If you set the mode to transaction mode, 6543 is transaction and 5432 is session. Setting the mode to transaction mode is irreversible from now since you can use both modes simultaneously with this config. If your pooling mode is already set to session, both 5432 and 6543 is set to session and you are encouraged to switch to transaction mode so that you can use both modes.

[ans-4175]

Hi @w3b6x9 I got this following error

FATAL: Authentication error, reason: "Authentication query failed: %Postgrex.Error{message: nil, postgres: %{code: :insufficient_privilege, file: \"aclchk.c\", line: \"3650\", message: \"permission denied for view pg_shadow\", pg_code: \"42501\", routine: \"aclcheck_error\", severity: \"ERROR\", unknown: \"ERROR\", where: \"SQL statement \\\"SELECT usename::TEXT, passwd::TEXT FROM pg_catalog.pg_shadow\\n    WHERE usename = p_usename\\\"\\nPL/pgSQL function pgbouncer.get_auth(text) line 5 at RETURN QUERY\"}, connection_id: 8812, query: nil}"
FATAL: Authentication error, reason: "Authentication query failed: %Postgrex.Error{message: nil, postgres: %{code: :insufficient_privilege, file: \"aclchk.c\", line: \"3650\", message: \"permission denied for view pg_shadow\", pg_code: \"42501\", routine: \"aclcheck_error\", severity: \"ERROR\", unknown: \"ERROR\", where: \"SQL statement \\\"SELECT usename::TEXT, passwd::TEXT FROM pg_catalog.pg_shadow\\n    WHERE usename = p_usename\\\"\\nPL/pgSQL function pgbouncer.get_auth(text) line 5 at RETURN QUERY\"}, connection_id: 8812, query: nil}"

after upgrade to Pg15. Before then I still connect using prev config (pooler) without any issues.
Any ideas on how to resolve from this one?

[w3b6x9]

Please create a support ticket. I’ll also ping our Pooler team now.

[dreamid27]

Yes, already.

the storage won't connect after upgrade, it's issue Pooler also ?

[w3b6x9]

Could be. Storage uses our Pooler (Supavisor) under the hood for its pooling solution

[dreamid27]

@w3b6x9 Hmm, oke.

"How long does it usually take for the pooler team to handle this issue?
"I have created a ticket, but there hasn't been any response until now."

[ans-4175]

Hmm, create a support ticket at https://supabase.help and our Pooler team can look into it.

Thanks, they help us swiftly and thorough