Persistent Session Pooler authentication failure after database password reset

[ecapture-ros]

Project ref: zgeasjkulipcfdjmbfvm

Direct DB connection is unavailable from my current IPv4-only network, so I’m using the Shared Session Pooler.

Connection parameters are copied directly from the Supabase Connect panel:

Session Pooler
port 5432
database postgres
user postgres.zgeasjkulipcfdjmbfvm
SSL required

I reset the database password, updated it immediately locally, and verified there are no quoting, whitespace, CRLF, duplicate-variable or URL-encoding issues.

A fresh psql test still returns:

FATAL: password authentication failed

The issue has persisted across multiple hours and two password resets.

Has anyone seen Supavisor remain out of sync with the project DB password, or is there another project-level setting I should check?

Additional diagnostic: both Shared Pooler modes fail with the same authentication error.
Session mode on port 5432: FATAL: password authentication failed
Transaction mode on port 6543: FATAL: password authentication failed
Same project, same username, same freshly reset database password, same pooler host copied from the Supabase Connect panel.
Please check Supavisor credential synchronization / tenant authentication for this project.

Support ticket: SU-482765

[DotDeon]

Two things worth doing before waiting on the ticket, because between them they resolve most of these.

1. Take URI encoding out of the picture entirely. Even when a password looks fine, %, @, #, & and : get mangled somewhere between clipboard, shell and URI more often than anyone expects. Reset the password once more to something plain alphanumeric, 24 characters or so, and test with connection parameters rather than a URI, with the password in the environment:

PGPASSWORD='...' psql "host=aws-0-<region>.pooler.supabase.com port=5432 dbname=postgres user=postgres.zgeasjkulipcfdjmbfvm sslmode=require"

If that works, the password was never the problem, the transport was. A surprising number of "verified no encoding issues" cases end here.

2. Bisect the pooler from the credentials. Same command on port 6543 (transaction mode). If 6543 works and 5432 does not, it's a Supavisor tenant issue and support needs to resync, which is exactly what your ticket is for. If both fail with the same error, it's still credentials or region.

On region: make sure the pooler host matches the project's region. A mismatched host normally gives Tenant or user not found, but I've seen it surface as a password failure when the username format is right and the host is wrong. Copy the host from the Connect panel again rather than from an older .env.

If a plain password on both ports still fails, it's on Supabase's side, and the ticket number you have is the right path.

[ecapture-ros]

Update: tested both shared pooler modes with the same verified credentials.
5432 session mode → password authentication failed
6543 transaction mode → password authentication failed
Host was copied again from the Connect panel.
So this is not session-mode-specific. Support ticket: SU-482765.

[somuai]

This issue typically occurs due to a credential desynchronization between PostgreSQL and the Supavisor connection pooler cluster rather than a client-side formatting error.

Root Cause: Supavisor ETS Cache Staleness

1. Architecture Separation: In Supabase, the database (PostgreSQL) and the connection pooler (Supavisor) run in separate environments. Supavisor maintains an in-memory ETS (Erlang Term Storage) cache of tenant secrets and user credentials to authenticate incoming connections on ports 5432 (Session mode) and 6543 (Transaction mode) without querying Postgres on every handshake.
2. Missed Invalidation Event: When you reset the database password via the Dashboard or Management API, Postgres updates the role password hash immediately. A control plane event is then dispatched to flush and update the cached tenant credentials in Supavisor. If this event is delayed, dropped, or fails to propagate across all pooler nodes, Supavisor retains the stale SCRAM/MD5 verifier in its cache.
3. Result: Incoming connections through aws-0-<region>.pooler.supabase.com on ports 5432 and 6543 fail SCRAM authentication against Supavisor, returning FATAL: password authentication failed for user "postgres.<project-ref>".

---

Recommended Resolution Steps

Before waiting for ticket SU-482765, you can force the control plane to synchronize Supavisor with PostgreSQL through the following actions:

1. Verify Direct Connection (Bypass Pooler)

Confirm that PostgreSQL itself has adopted the new password by connecting directly (note: requires direct IPv6 or IPv4 Add-on):

PGPASSWORD='<new_password>' psql -h db.<project-ref>.supabase.co -p 5432 -U postgres -d postgres -v sslmode=require

If direct connection succeeds, the password is functional in Postgres and the failure is confirmed to be isolated to the pooler cache.

2. Force Supavisor Tenant Reload via Dashboard

You can trigger an immediate tenant reload in Supavisor without downtime:

1. Navigate to Project Settings > Database > Connection Pooling.
2. Note your current pool size settings, change the Default Pool Size by 1 (or toggle the Pool Mode), and click Save.
3. Revert the value back to your desired size and click Save again.
   Saving pooler settings broadcasts an immediate tenant configuration update across the Supavisor cluster, which evicts stale ETS auth cache entries and pulls fresh credentials from the control plane.

3. Trigger a Fast Reboot (If Cache Persists)

If the pooler configuration save does not immediately clear the cached credential:

1. Navigate to Project Settings > General > Restart project.
2. Select Fast reboot and confirm.
   Fast reboot restarts the database container and re-registers the project with the control plane, ensuring all external proxies and pooler nodes synchronize their auth state.