Supabase Free project: both pooler connections fail with ENOTFOUND tenant/user

[saleemupk1-sudo]

Hello Supabase community,

I need help troubleshooting a PostgreSQL connection issue with my Supabase Free Plan staging project.

Project details

• Region: South Asia (Mumbai), ap-south-1
• The project dashboard shows the project as Healthy.
• Supabase CLI link succeeds.
• The Project Settings API returns HTTP 200.

Problem

Both connection pooler modes fail:

• Session pooler, port 5432
• Transaction pooler, port 6543

Both return an error similar to:

FATAL: (ENOTFOUND) tenant/user <project-specific database username> not found

The Supabase CLI database dump also fails with this error, so I have not been able to create a valid database backup. The resulting SQL file was empty.

I copied the connection details directly from the Supabase Dashboard and tried both pooler modes. I have not applied any migrations during troubleshooting.

Could anyone advise how to troubleshoot a Supavisor tenant/user lookup error and verify the correct pooler hostname and username?

Thank you!

[cekuu35]

A project-wide ENOTFOUND (both pooler modes, standard connection details copied from the dashboard) is a different situation from the custom-role version of this error — it usually means the pooler's tenant registration for your project is out of sync rather than anything wrong with your connection string. Three checks worth running in order:

1. Verify the hostname prefix explicitly. The most common cause of this error across regions is the aws-0 vs aws-1 prefix. Copy it character by character from Dashboard → Connect — not from memory or an older note. The correct format for Mumbai should be aws-0-ap-south-1.pooler.supabase.com (or aws-1-... if your project is on the newer edge). A quick sanity check from the same machine:

nslookup <pooler-hostname>

If it resolves, the connection reaches Supavisor and the ENOTFOUND is a tenant lookup (registration issue). If it doesn't resolve, it's DNS — which means a different problem, not a Supavisor one.

2. Recent pause/resume? Free-tier projects pause after inactivity and re-provision on resume. The Postgres core can report Healthy while Supavisor's tenant registration is still catching up — the dashboard "Healthy" checks the database, not necessarily the pooler's routing table. If the project was paused recently: wait 10–15 minutes and retry, before anything else. The CLI link succeeding tells you the management API is up; it doesn't validate the pooler's tenant state.

3. The definitive test that isolates the pooler entirely:

psql "postgresql://postgres:<password>@db.<project-ref>.supabase.co:5432/postgres" -c "select 1"

That's the direct connection — it bypasses Supavisor completely. On the Free plan it resolves IPv6-only, so run it from a host with IPv6 (or note the failure separately). If direct works and both pooler modes give ENOTFOUND, the connection details are fine and the tenant registration needs the support-side refresh — which is exactly the evidence that makes a support ticket resolve fast.

The CLI dump failing is expected in this state — it uses the same pooler route for its connection. Your backups will start working the moment the pooler tenant resolves; nothing separate to fix there.

For the deeper version of this troubleshooting (custom roles through the pooler, the user-registry sync behavior, and the pg_dump compatibility notes), the adjacent thread has the full map: #51587 (comment)

[tisankanj]

There is a useful distinction in that exact error: FATAL: (ENOTFOUND) tenant/user ... not found is a PostgreSQL-protocol error returned by the pooler. It is different from a client-side getaddrinfo ENOTFOUND <hostname> DNS failure. A successful nslookup only proves name resolution; it does not prove that the host/username pair routes to your project.

Supabase now has an official Tenant or user not found guide, updated October 14. It specifically warns against deriving the pooler hostname from the region: the aws-N number is a cluster index, not an old/new designation, and aws-0 is not a safe default. For the shared pooler, the username is postgres.<project-ref> (or <role>.<project-ref> for a custom role), whereas a direct connection uses the unsuffixed role.

Since you already copied the Dashboard details, I would verify what the failing process actually uses, without printing the password:

• Compare the effective host, port, database and username with the selected Connect mode. Check for an older environment value, a different project reference, or a tool overriding the username. Inspect these locally and redact project identifiers before sharing logs.
• Test the session-pooler combination directly with an existing psql client. For example, substitute the exact Dashboard values and let -W prompt for the password rather than putting it in shell history:

psql -h <dashboard-session-pooler-host> -p 5432 \
  -U postgres.<project-ref> -d postgres -W \
  -c "select 1 as connection_ok;"

If this succeeds but the CLI dump fails, compare the CLI's effective connection and version; that is a different branch from both tools receiving the same pooler FATAL. If both verified pooler modes still fail, send Support the sanitized host/port/username, UTC timestamps and exact error. That supports investigation without assuming an internal registration fault or trying a restart.

A successful direct connection is useful additional evidence, but it does not prove the shared-pooler credentials are correct because its hostname and username format differ. Also account for direct-connection IPv6 reachability. Connection modes and formats.

Finally, keep the empty dump marked as failed. After connectivity is restored, check the dump command's exit status and stderr, and validate the backup by restoring it into a separate disposable database before relying on it. Fixing the connection alone does not validate a backup. I cannot inspect the hosted pooler state from this thread.