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.

@ecapture-ros

That log line provides the exact clue needed to pinpoint what is happening inside the connection pooler.

The Architectural Meaning of Your Supavisor Log

ClientHandler: Exchange error: password authentication failed for user "postgres"
SecretChecker not started, using a one-off auth query connection

In Supavisor (lib/supavisor/client_authentication.ex and lib/supavisor/secret_checker.ex):

1. Supavisor Did NOT Use Stale Credentials:
   SecretChecker is the background GenServer responsible for maintaining the in-memory cache of tenant secrets. When Supavisor logs:
   SecretChecker not started, using a one-off auth query connection
   it means no cached secret was used.
   Instead, Supavisor's ClientAuthentication fell back to AuthQuery.connect_and_fetch_user_secret, which dynamically established a real-time connection directly to your PostgreSQL database, queried pg_shadow on the fly, and fetched the live SCRAM-SHA-256 verifier currently stored in PostgreSQL.

2. The Resulting Error is WrongPasswordError (Not PasswordChangedError):
   Supavisor distinguishes between a mid-session password change and an outright mismatch:

   • If secrets changed after cache initiation, it emits PasswordChangedError ("password was recently changed").
   • Because it fetched the live secret via the one-off connection and the SCRAM handshake client proof still failed, it raised WrongPasswordError ("password authentication failed for user \"postgres\"").

This proves that Supavisor is not holding a stale credential for zgeasjkulipcfdjmbfvm—it queried PostgreSQL in real time, and the password your client provided did not match the password stored in Postgres for postgres.

Why Does This Occur After a Dashboard Reset?

1. Dashboard Password Reset Failed or Rolled Back:
   Occasionally, when resetting the database password through the Dashboard UI (Project Settings -> Database -> Database Password), if the control-plane orchestration worker times out or encounters a lock, the UI may indicate completion while PostgreSQL remains on the previous password.
2. URI Character Encoding Mangle:
   If your new password contains symbols such as #, @, :, /, ?, %, &, [, ], !, or $, connection strings formatted as postgresql://user:pass@host:port/db get broken or truncated by client URL parsers (e.g. # is parsed as a fragment identifier, @ splits user/host).
3. Hidden Characters or Quotes:
   Copying credentials from password managers or .env files can introduce surrounding single/double quotes or trailing newline characters (\n).

The 60-Second Resolution (Bypassing the Dashboard & Support Ticket)

Because the Supabase Dashboard SQL Editor runs over an internal admin connection that does not require your postgres password, you can set the password directly inside PostgreSQL and eliminate all control-plane ambiguity.

Step 1: Force Set the Password Directly via SQL Editor

1. Open your Supabase Dashboard for project zgeasjkulipcfdjmbfvm.
2. Go to SQL Editor and run:

   ALTER USER postgres WITH PASSWORD 'YourNewCleanPassword123';

   (For this test, use a clean alphanumeric password without special characters like #, @, %, or quotes).

Step 2: Test with Connection Parameters (Avoid URI Parsing)

Test connecting through Supavisor using explicit key-value parameters rather than a connection URI:

Session Mode (Port 5432):

PGPASSWORD='YourNewCleanPassword123' psql "host=aws-1-eu-west-1.pooler.supabase.com port=5432 dbname=postgres user=postgres.zgeasjkulipcfdjmbfvm sslmode=require"

Transaction Mode (Port 6543):

PGPASSWORD='YourNewCleanPassword123' psql "host=aws-1-eu-west-1.pooler.supabase.com port=6543 dbname=postgres user=postgres.zgeasjkulipcfdjmbfvm sslmode=require"

Step 3: If Using a Connection String URI

If your application requires a connection string URI, ensure the password is URL-encoded:

postgresql://postgres.zgeasjkulipcfdjmbfvm:[ENCODED_PASSWORD]@aws-1-eu-west-1.pooler.supabase.com:5432/postgres

(e.g., if you later add special characters, encode # as %23, @ as %40, % as %25).

Once you execute the ALTER USER query in the SQL Editor, the one-off auth_query in Supavisor will immediately pick up the updated SCRAM verifier on your next connection attempt.