Password authentication

[jacobscup]

I’m using the Free plan. I reset my project’s database password, but the Session pooler still returns FATAL: password authentication failed for user "postgres" on port 5432. The project ref is ivfakupzejzzsekgwnrq. Could you advise how to resolve this?

[cekuu35]

The most common cause after a database password reset on the newer poolers is the username format, not the password itself: the Supavisor connection requires the project-ref-qualified username, not plain postgres.

For your project, the session-pooler connection should be:

postgresql://postgres.ivfakupzejzzsekgwnrq:[NEW-PASSWORD]@aws-0-<region>.pooler.supabase.com:5432/postgres

Note postgres.ivfakupzejzzsekgwnrq — the .ivfakupzejzzsekgwnrq suffix is required on the pooler (both 5432 session and 6543 transaction). A connection string that worked before with plain postgres against the direct connection will fail with exactly your error (password authentication failed for user "postgres") the moment you route it through the pooler, because the pooler routes by the username suffix and falls back to legacy auth when it's missing.

Verification order after any password reset:

1. Direct first (bypasses the pooler entirely): postgresql://postgres:[NEW-PASSWORD]@db.ivfakupzejzzsekgwnrq.supabase.co:5432/postgres — plain postgres is correct here. If this fails, the reset didn't take or the password has a character that needs URL-encoding in the string.
2. Then the pooler: same password, but username postgres.ivfakupzejzzsekgwnrq. If direct works and the pooler still fails right after a reset, the session pooler is holding cached auth for your old verifier — pooler sessions recycle on their own within minutes, or disconnect everything (dashboard → Connections shows active sessions) to force it.

On special characters in the new password: the reset accepts them, but the connection string needs them percent-encoded (@ → %40, : → %3A, / → %2F, spaces → %20). A mismatch there produces the same FATAL while the password is actually correct — worth checking before anything else.

If the pooler authenticates but your app still fails, the app's cached string is the culprit (restart after rotating the env var).

For what's recorded in logs during this (statement logs capture the ALTER ROLE with the new verifier when you reset via the dashboard, and the pooler's own diagnostics are separate) — the credential-lifecycle details are in the adjacent threads: #51544 and #51499