Password authentication failing on ALL connection methods

[marcos3959]

Hi, I've been stuck on this for a while and hoping someone in the community has run into it before.

Authentication for the "postgres" user is failing with
"FATAL: password authentication failed for user postgres"
across ALL connection methods tested:

• Direct connection (port 5432)
• Session pooler (port 5432)
• Transaction pooler (port 6543)

What I've already tried, with no success:

1. Reset the database password multiple times via the dashboard (Project Settings > Database > Reset database password), always copying the password directly from Supabase's confirmation screen (never typed manually).
2. Tested the original password (prior to the first reset) — also fails now.
3. Tested all 3 connection methods (Direct, Session pooler, Transaction pooler).
4. Confirmed "Enforce SSL on incoming connections" is OFF.
5. Added "?sslmode=require" to the connection string — same error.
6. Confirmed "Network Restrictions" is set to allow access from any IP (no restriction).
7. Waited more than 12 hours between a password reset and the next test, to rule out propagation delay.
8. Connection string format double-checked each time: no special characters in the password, no leftover brackets, no stray whitespace.

The application (running on Render, Python/FastAPI with psycopg2) has been down in production because of this.

Has anyone seen Supabase reject the postgres password like this, with everything else checking out? Any debugging ideas appreciated.

[GaryAustin1]

Make sure your password does not have any special characters in it. This is especially an issue if you use url connection strings to connect as then you have to deal with url encoding.

Try PSQL or similar and see if another method works.

[VioletGorilla85]

A password failure that survives multiple resets usually isn't the password — the first thing I'd check here is the username you're sending to the poolers.

The Supavisor poolers (both the session pooler on 5432 and the transaction pooler on 6543, host aws-<n>-<region>.pooler.supabase.com) require a tenant-qualified username: postgres.<PROJECT_REF>. Only the direct connection (db.<PROJECT_REF>.supabase.co:5432) takes bare postgres. If a pooler gets the bare username it can't resolve which project you mean, and it returns exactly FATAL: password authentication failed for user "postgres" — forever, no matter how many times you reset. That would neatly explain "all three methods fail after every reset": two of the three are failing on the username, and the third on something else.

For the direct connection, the usual survivor-of-resets is the password being mangled between the clipboard and the wire. Two specific cases: a % or + inside a URL-style DSN (psycopg2 will URL-decode it), and — the invisible classic — a trailing newline picked up when pasting into a Render environment variable. "No special characters" doesn't cover a trailing \n.

You can settle all of it in one pass with psql, which takes the DSN and URL-encoding out of the equation:

# 1) pooler — username MUST carry the project ref
PGPASSWORD='<paste exactly>' psql -h aws-1-<region>.pooler.supabase.com -p 6543 \
  -U postgres.<PROJECT_REF> -d postgres -c 'select 1'

# 2) direct — bare username here
PGPASSWORD='<paste exactly>' psql -h db.<PROJECT_REF>.supabase.co -p 5432 \
  -U postgres -d postgres -c 'select 1'

# 3) catch the invisible newline in what Render actually stored
printf '%s' "$PGPASSWORD" | wc -c    # must equal the visible character count

How it decodes: (1) works but your app still fails → the bug is in the app's connection string on Render. (1) fails but (2) works → it was the pooler username all along. Both fail and wc -c is off by one → trailing newline. All three clean and it still fails → then it's genuinely on the platform side and worth a support ticket with these results attached, which will shortcut their triage.