Session pooler returns ENOTFOUND tenant/user not found in us-east-1

[acmg-albert]

Need help!
I am now seeing the same project-specific Session pooler issue in us-east-1.

The project is active and healthy, and the application/API continues to work.
However, Supabase CLI database connections fail before any SQL is executed.

Observed behavior:

1. The passwordless CLI flow hangs at:

   Initialising login role...

2. After explicitly supplying the database password through
   SUPABASE_DB_PASSWORD, the exact Dashboard-provided Session pooler connection
   returns:

   FATAL: (ENOTFOUND) tenant/user postgres. not found
   (SQLSTATE XX000)

3. Dashboard → Connect confirms:

   Host: aws-0-us-east-1.pooler.supabase.com
   Port: 5432
   Database: postgres
   User: postgres.

Additional checks already completed:

• No Network Bans are listed.
• Network Restrictions allow all IP addresses.
• supabase link completes successfully.
• The database password was reset once.
• The project was restarted once, but the problem persists.
• --skip-pooler was tested, but the current client network is IPv4-only.
• No migration SQL has been executed.

This remained reproducible after waiting overnight.

Supabase Support ticket: SU-464160

Since this appears identical to the issue reported here, could someone from
Supabase confirm whether affected projects need their Supavisor tenant/routing
registration refreshed or re-provisioned server-side?

I can provide exact timestamps privately through the support ticket.

[GaryAustin1]

Double check aws-0 versus aws-1 or aws-2 in your connection string.

What is the full user name you are using (mask your project id). Should be postgres.project_id and not just postgres.

[acmg-albert]

Thanks for the suggestion. I double-checked the Session Pooler values shown in Dashboard > Connect.

• Host: aws-0-us-east-1.pooler.supabase.com
• Port: 5432
• Database: postgres
• Username format: postgres.
• My masked username is: postgres.xbxo…gtvk

So I am using the full pooler username, not just "postgres". I also did not manually guess the aws-N prefix — aws-0 is copied directly from the project’s Connect panel.

The Supabase CLI selects the same host and username after a successful:

supabase link --project-ref

But the subsequent linked database command fails with:

FATAL: (ENOTFOUND) tenant/user postgres.xbxo…gtvk not found (SQLSTATE XX000)

Additional checks already completed:

• The project is active and the application/database APIs work.
• The project was restarted.
• The database password was reset.
• The project was unlinked and relinked.
• Network restrictions allow all IP addresses.
• There are no network bans.
• Direct connection with --skip-pooler cannot be used from this network because it does not support IPv6.
• Supabase CLI v2.115.0 was used.
• A database migration was successfully applied through the Dashboard SQL Editor, so the database itself is accessible and healthy.
• Support ticket: SU-464160.

Could the Session Pooler tenant mapping shown by the Dashboard be stale or not propagated correctly? Is there a safe way to verify or refresh the project’s assigned pooler host/tenant mapping without recreating the project?

[acmg-albert]

Thanks for the suggestion. I double-checked the Session Pooler values shown in Dashboard > Connect. - Host: aws-0-us-east-1.pooler.supabase.com - Port: 5432 - Database: postgres - Username format: postgres.<project-ref> - My masked username is: postgres.xbxo…gtvk So I am using the full pooler username, not just "postgres". I also did not manually guess the aws-N prefix — aws-0 is copied directly from the project’s Connect panel. The Supabase CLI selects the same host and username after a successful: supabase link --project-ref <project-ref> But the subsequent linked database command fails with: FATAL: (ENOTFOUND) tenant/user postgres.xbxo…gtvk not found (SQLSTATE XX000) Additional checks already completed: - The project is active and the application/database APIs work. - The project was restarted. - The database password was reset. - The project was unlinked and relinked. - Network restrictions allow all IP addresses. - There are no network bans. - Direct connection with --skip-pooler cannot be used from this network because it does not support IPv6. - Supabase CLI v2.115.0 was used. - A database migration was successfully applied through the Dashboard SQL Editor, so the database itself is accessible and healthy. - Support ticket: SU-464160. Could the Session Pooler tenant mapping shown by the Dashboard be stale or not propagated correctly? Is there a safe way to verify or refresh the project’s assigned pooler host/tenant mapping without recreating the project?

…

On Sat, Sep 5, 2026 at 8:24 AM GaryAustin1 ***@***.***> wrote: Double check aws-0 versus aws-1 or aws-2 in your connection string. What is the full user name you are using (mask your project id). Should be postgres.project_id and not just postgres. — Reply to this email directly, view it on GitHub <#50040?email_source=notifications&email_token=BPIO4LQX5MJZF4GLZJ7RPWD5NQAZPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBTGA2DANBTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18304043>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BPIO4LVPEWOXNI2NHO6Q5635NQAZPAVCNFSNUABIKJSXA33TNF2G64TZHMZDCNBVHA3TCOJTHNCGS43DOVZXG2LPNY5TCMBXGU2TANZSUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BPIO4LVWP5R6OCGWYRS72D35NQAZPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBTGA2DANBTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/BPIO4LWK4VGT2NLAYOXTITL5NQAZPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBTGA2DANBTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[GaryAustin1]

This was a similar issue a few days ago and a response from a dev.
Basically checking what I did just asked.
https://discord.com/channels/839993398554656828/1543857483905241088

The only control you have is to restart the instance (reboot) or upgrade to change out the actual instance it is running on.

[acmg-albert]

Thanks — the linked Discord thread is helpful.

It appears that Supabase staff were able to distinguish two different errors from the internal pooler logs:

1. ENOTFOUND caused by connecting to the wrong pooler host.
2. EAUTHQUERY caused by an incorrectly constructed role/tenant username.

My case uses the built-in postgres role rather than a custom SQL-created role. The Session Pooler details copied directly from Dashboard > Connect are:

• Host: aws-0-us-east-1.pooler.supabase.com
• Port: 5432
• Database: postgres
• Username format: postgres.

The Supabase CLI also selects the same aws-0 host and the same username automatically after linking. The project has already been restarted, but the same ENOTFOUND tenant/user error remained.

The project itself is healthy: Dashboard SQL Editor works, the application APIs work, and Edge Functions can be deployed. Only the Supavisor database connection fails.

Could Supabase staff check the internal pooler logs and confirm whether aws-0 is actually the pooler host assigned to this project, or whether the project’s Supavisor tenant mapping needs to be refreshed?

Support ticket: SU-464160

[GaryAustin1]

I'm sure they can check but that is what tickets are for. Normally staff does not check Github posts or even most discord threads, but that particular dev has checked in a bit there. Note though you have to go thru support for anyone to actually touch your project.

Also just in case make sure your password does not have any special characters. This can sometimes mess up the url processing if not url encoded and impact more than just the password itself.

[acmg-albert]

Thank you — understood. I already have Support ticket SU-464160 open, so I’ll wait for Support to inspect the project-side pooler mapping.

For the password test, I passed the database password as the raw SUPABASE_DB_PASSWORD environment variable and used db push --linked. I did not embed the password in a PostgreSQL connection URL, so URL percent-encoding should not be involved.

I will not post the password or complete connection string publicly. Thanks again for helping narrow this down.

[VioletGorilla85]

Your own read looks right to me, and there are a few things worth adding that should keep the ticket pointed the right way.

ENOTFOUND here is not DNS. That string is Supavisor's tenant lookup failure — it resolved and connected to the pooler fine, then failed to find a tenant registration matching postgres.<project-ref> and closed the connection with XX000. It's worth stating that explicitly in SU-464160, because "ENOTFOUND" reads like a Node/DNS error and can send triage toward DNS and network bans, which you've already cleared. The host resolving and answering is exactly what makes this a server-side registration problem rather than anything on your side.

supabase link succeeding doesn't contradict that. Link talks to the Management API over HTTPS, not to Postgres through Supavisor, so it can succeed while the pooler tenant is missing. Same for "project is active and healthy" and your app still working — if your app connects over IPv6 direct or an existing connection, it never touches the failing path.

Two checks that will sharpen the ticket:

1. Take the CLI out of it. Same credentials, raw client:

   psql "postgresql://postgres.<ref>:<password>@aws-0-us-east-1.pooler.supabase.com:5432/postgres" -c 'select 1'

   Identical tenant/user ... not found from psql proves it's server-side and not CLI login-role handling. That single line is usually enough to move a ticket past first-line triage.

2. Try the transaction pooler on 6543 with the same username:

   psql "postgresql://postgres.<ref>:<password>@aws-0-us-east-1.pooler.supabase.com:6543/postgres" -c 'select 1'

   If 6543 works while 5432 fails, that narrows it to the session-mode registration specifically — a much more precise thing for them to re-provision. It may also unblock you in the meantime: transaction mode is fine for one-shot SQL and most CLI work, though note it doesn't support session-level state (prepared statements, SET that must persist, advisory locks), so db push on a complex migration can still misbehave there.

Given IPv4-only egress, those two are the useful ones — I'd skip further --skip-pooler attempts, since direct db.<ref>.supabase.co is IPv6-only unless the IPv4 add-on is enabled, so that path can't succeed from your network regardless of whether the pooler is healthy.

Nothing here is fixable from your side if both ports return tenant-not-found; at that point it is re-provisioning and only Supabase can do it. But the psql result plus the 5432-vs-6543 comparison is the evidence that gets that done fastest.

[acmg-albert]

I completed both raw psql tests. Thank you — this was very useful.

Both the Session Pooler on 5432 and Transaction Pooler on 6543 resolved the host and reached Supavisor, but both returned the identical:

FATAL: (ENOTFOUND) tenant/user postgres. not found

Both exited with code 2. The password was supplied through PGPASSWORD, not embedded in the URL.

I have added these results to Support ticket SU-464160. This now appears to be a project-side Supavisor tenant registration or pooler-host assignment issue.

[VioletGorilla85]

That result is decisive, and it rules out more than it might look like.

Both modes failing identically is the important part. Session (5432) and transaction (6543) are different pooling behaviours in front of the same tenant record, so if only 5432 had failed we'd be looking at session-mode registration. Both failing at the same point means the lookup never gets far enough to care which mode you asked for — the tenant key itself isn't resolving. Combined with the project being Healthy and your app still working, that's a clean split: the database is fine, the Supavisor mapping in front of it is not. Exactly the shape of thing only Supabase can fix.

One more test worth attaching to SU-464160, because it closes the last loophole: run the same command with a deliberately wrong password.

PGPASSWORD='definitely-not-the-real-password' psql \
  "postgresql://postgres.<ref>@aws-0-us-east-1.pooler.supabase.com:6543/postgres" -c 'select 1'

If the tenant existed, a bad password has to fail later in the sequence — you'd get an authentication error (EAUTHQUERY, or a password authentication failure). If you instead get the same ENOTFOUND tenant/user ... not found, that proves the request dies at tenant lookup before credentials are ever evaluated. That single contrast is the cleanest possible evidence that this is registration and not credentials — and it should stop the "please reset your database password again" loop that these tickets usually get stuck in. It's read-only and safe: nothing is created, and no valid secret is transmitted.

Worth stating plainly in the ticket alongside it: password was supplied via PGPASSWORD, never in the URL, so percent-encoding is not a factor; both pooler ports were tested outside the CLI; and the project has already been restarted once without effect. That closes off the three things first-line triage will otherwise ask you to redo.

To keep shipping while you wait: since your egress is IPv4-only, the direct db.<ref>.supabase.co host isn't reachable for you regardless of pooler health, so there's no client-side workaround to find. What does still work is the Dashboard SQL Editor — it goes over HTTPS and never touches Supavisor. If you have migrations queued, supabase db diff (or the SQL already in supabase/migrations/) gives you the statements, and you can apply them there in order as a stopgap. Not ideal for a real migration pipeline, but it keeps you unblocked rather than idle until support re-registers the tenant.

[acmg-albert]

Confirmed — the deliberately wrong password returned the exact same result:

FATAL: (ENOTFOUND) tenant/user postgres. not found
Exit code: 2

It did not reach password authentication or return EAUTHQUERY. This confirms that Supavisor is failing tenant lookup before evaluating credentials.

I have added this final diagnostic result to Support ticket SU-464160. Thank you for suggesting the test.

[VioletGorilla85]

That's a complete proof chain now, and there's nothing further to test from your side.

What you've established, in the order support will want it: the host resolves and Supavisor answers (so not DNS, not network bans, not restrictions); both session and transaction modes fail identically (so not a session-mode quirk); it reproduces outside the CLI with PGPASSWORD (so not the CLI, not URL encoding); and an intentionally wrong password returns the same tenant-not-found rather than an auth error (so the failure precedes credential evaluation entirely). That last one is what makes it unarguable — no password reset can fix a lookup that never reaches the password.

Two things worth asking SU-464160 for explicitly, since they're the actions only they can take:

1. Re-register / repair the Supavisor tenant mapping for the project ref.
2. Confirm which pooler host the project is actually assigned to. The Connect panel gives you aws-0-us-east-1, but if the project was moved or re-provisioned, a stale host in the panel would produce exactly this symptom — and that's invisible from your side. Asking them to confirm the assignment (rather than assuming aws-0) sometimes shortcuts the whole thing.

You'll know it's fixed the moment select 1 returns 1 on either port with the real password — no restart, redeploy, or password change needed on your end, since nothing about your project's configuration was ever wrong. Until then the Dashboard SQL Editor stays your route for anything urgent, because it's HTTPS and never touches the pooler.

Good luck with it — you diagnosed this carefully, and the ticket is in much better shape than most.

[acmg-albert]

Thank you very much. I agree that the client-side diagnostic chain is now complete. I will ask Support explicitly to repair the Supavisor tenant mapping and confirm the project’s actual assigned pooler host.