Shared Supavisor pooler returns ENOTFOUND tenant/user not found for a custom Postgres role

[omargawi]

Hello!

I'm trying to connect a custom Postgres role through Supabase's shared Session Pooler, but Supavisor returns a tenant/user-not-found error.

Environment:

• Plan: Free
• Region: eu-west-2
• Pooler: shared Session Pooler, port 5432
• Role: personal_os_backup_reader

Error:
FATAL: (ENOTFOUND) tenant/user personal_os_backup_reader.[PROJECT-REF] not found

I'm using the documented [ROLE].[PROJECT-REF] username format and the pooler hostname copied from the Supabase Connect configuration.

The role exists in Postgres and has been verified as LOGIN, NOINHERIT, and NOBYPASSRLS, with no role expiration.

Troubleshooting completed:

1. Verified the role and its attributes directly in Postgres.
2. Confirmed the pooler hostname and project reference.
3. Rotated the role password and updated the protected connection configuration.
4. Paused and resumed the project.
5. Retested; the same tenant/user-not-found error persists.

The purpose is a least-privilege, encrypted off-site logical-backup system. Our synthetic backup pipeline passes encryption, private storage, retrieval, decryption, integrity, and cleanup tests. Real Production backups are blocked at database connection establishment.

Questions:

1. Has anyone resolved this error for a custom Postgres role using Supabase's shared Session Pooler?
2. Is there a supported way to refresh or repair the Supavisor tenant/user mapping without recreating the project?
3. If this is a limitation, what secure, $0-cost alternative would you recommend for automated logical backups on the Free plan?

We want to preserve least privilege and avoid using the postgres administrator role as a workaround.

Thanks for any guidance.

[saraeloop]

I think there are two separate problems here, and it's worth splitting them up.

First, the pooler error. Your full message is a FATAL coming back from the pooler, so it reached Supavisor (a bare ENOTFOUND on its own can also mean a DNS failure, so the full text matters). An easy way to narrow it down is to connect with the same host and port, but as postgres.<project-ref>.

If that fails the same way, it points to a shared connection or routing problem rather than something specific to your role, though it still doesn't validate the custom role. I'd double-check the number in the hostname (aws-0-… vs aws-1-…), since that's tripped people up before (routing guide). If the effective host, port, username, and project ref all match what the Connect panel shows, collect the exact error and contact support.

If postgres connects fine, then it's specific to your role. Custom roles don't need any extra setup for the shared pooler. The username is just <role>.<project-ref> (docs). Also, after a password change, the pooler can take around 15 seconds to catch up.

On the $0 alternative: the direct connection (db.<project-ref>.supabase.co:5432, plain role name, no suffix) works on Free, but only over IPv6. The IPv4 add-on is paid (connection modes). So it depends on whether the machine running your backups has IPv6. Many hosted CI runners don't, and if yours doesn't, the session pooler is the documented IPv4 alternative for this workflow.

Heads up for once you're connected: pg_dump turns off row security and exports either every row of a table or none. So an ordinary non-owner backup role that's subject to RLS will fail when it reaches those tables. Supabase's own backup-role guide uses bypassrls plus pg_read_all_data (guide). I'd avoid --enable-row-security as a workaround, because it quietly dumps only the rows the role can see, so you'd end up with an incomplete backup without knowing it.

If you go that route, be aware of what it grants. pg_read_all_data lets the role read everything in the database, including auth and storage. That makes sense for a full-database backup. If you only need specific tables, keep narrower grants instead.

Since your role is NOINHERIT, there's one more catch: on Postgres 16+, granting it pg_read_all_data won't actually give it those privileges unless you ask for inheritance explicitly:

alter role personal_os_backup_reader bypassrls;
grant pg_read_all_data to personal_os_backup_reader with inherit true;
alter role personal_os_backup_reader set default_transaction_read_only = on;

The last line protects against accidental writes, but it's only a default that a session can turn off, so don't treat it as a security boundary.

Run pg_dump directly instead of supabase db dump. The CLI switches to the postgres role, so it'll fail with a restricted role.

And once a dump succeeds, try restoring it somewhere. A clean export isn't a proven backup until you've restored it.

Hope that helps!

[cekuu35]

Adding three angles to @saraeloop's diagnosis, because the combination of custom role + shared pooler + Free plan has specific failure pockets worth separating:

1. The pooler's user registry is a separate store, and it syncs on its own schedule.

Supavisor doesn't read pg_roles live — it maintains its own tenant/user mapping, and a role created via the SQL editor doesn't appear in it instantly. If personal_os_backup_reader was created recently, retrying the same connection a few hours later is genuinely informative (and worth doing before the support ticket — "worked after N hours" vs "still failing after N days" changes the ticket entirely). Pause/resume doesn't force this registry to re-sync (as you observed), and there is no self-serve refresh — your question 2's supported answer is the support ticket, which is the right next move given everything you've already ruled out.

2. The direct-connection fallback has an IPv6 trap on the Free plan.

Before concluding the pooler is the only path: db.<project-ref>.supabase.co:5432 (direct) accepts your custom role with plain personal_os_backup_reader as the username (no .ref suffix — that's pooler-only syntax) and the role's own password. But on the Free plan the direct hostname is IPv6-only — if your backup host (a GitHub Actions runner, most cloud VMs, most home networks) is IPv4-only, the connection fails at DNS/connect, which looks like the same class of problem. Worth one explicit test from your backup host:

nslookup db.<project-ref>.supabase.co

AAAA records only → the direct path is closed from that host without the IPv4 add-on, and the pooler is genuinely your only route — which strengthens the support case rather than weakening it.

3. The backup-architecture note: pg_dump and the pooler don't mix well anyway.

For your actual goal (least-privilege automated logical backups), one compatibility point worth knowing before you invest more in the custom-role-via-pooler route: pg_dump over a transaction pooler (6543) fails on prepared-statement/locking behavior, and while the session pooler (5432, your current attempt) works for ordinary sessions, some dump/restore tooling misbehaves behind any pooled connection. If the support ticket resolves the mapping, test a full pg_dump --schema=public through it before trusting the pipeline — the connection establishing is necessary but not sufficient evidence that the dump completes cleanly.

The $0 least-privilege-adjacent alternative most people land on for Free-tier backups: a scheduled supabase db dump via the CLI in a private GitHub Actions runner, authenticated with the project's SUPABASE_ACCESS_TOKEN (not the custom role — it runs as postgres). It sacrifices the role-scoping you want, so it's a fallback, not an equivalent — but it unblocks production backups while the ticket resolves the pooler mapping. Your least-privilege design is the right target; the two constraints (Free plan + custom role through shared Supavisor) are just fighting each other in a way only support can fix.