Supavisor error: "password authentication failed" after rotating database password

Last edited: 9/11/2026

If connections through the Shared Pooler (Supavisor) (aws-[...].pooler.supabase.com, port 5432 in session mode or 6543 in transaction mode) start failing with password authentication failed for user "..." shortly after you change your database password, even though the new password is correct, this is expected behavior, not a bug — it isn't something you need to treat as a problem unless it persists.

Ports 5432 and 6543 are also used by the direct connection and the Dedicated Pooler, but on a different host, db.[project-id].supabase.co. Those aren't affected by this.

This applies to regular database roles authenticating with a username/password (including SCRAM, the default). It does not apply to JIT access-token connections, since those are validated live against the JIT provider on every connection rather than against a cached password.

Why Does This Happen?

The connection pooler caches database credentials briefly for performance.
Right after a password change, the pooler may keep checking new connection attempts, which use the correct new password, against the old, cached credentials, and reject them as a result.

How to Resolve This:

These steps cover the pooler-side caching delay, which resolves on its own.

Separately, if application instances keep connecting with the old password after changing an existing role's credential, those failed attempts can trip the auth circuit breaker, blocking connections from that client and disrupting the system further.

To roll out a password change without downtime, create a new custom role with the new password alongside the existing one, migrate your clients over to it gradually, then retire the old role once every client has switched.

First, confirm the new password is correct by connecting directly (bypassing the pooler), using a Postgres client such as psql with the new password. A successful direct connection supports the transient pooler-cache diagnosis. If the direct attempt fails, check whether the error is an authentication failure such as 28P01 before concluding that the password is wrong.
If the direct connection works, retry through the pooler. A new connection attempt is generally what causes the pooler to pick up the new password. If your database already has active pooled connections, this also tends to happen automatically in the background within about 15 seconds; if the pool had gone idle before you rotated the password, nothing happens on its own — you need an actual reconnect attempt to trigger it.
In rare cases, rate limiting or network delays can cause a few consecutive reconnect attempts in a row to fail before one succeeds.
Avoid rotating the password multiple times in quick succession as each change restarts the same window and makes it harder to tell which attempt should be succeeding.
If the direct connection works but pooler reconnects still fail after a few minutes, contact support and mention that the direct connection was verified working, so the transient-cache path can be ruled out.

See also: