Persistent PostgreSQL 28P01 on Direct connection after two database password resets

[asawaku1632]

Hi,

I'm troubleshooting a persistent PostgreSQL authentication failure on a Supabase DEV project using a Direct database connection.

I have already opened Supabase Support ticket SU-474350, but since this is a Free-plan project and the issue is still unresolved, I'm also asking the community for help.

Environment

Connection method: Direct
Port: 5432
Database: postgres
User: postgres

I am intentionally not posting the project ref, full hostname, connection URI, password, or any other credentials.

The application/probe must use a Direct connection. Switching to the transaction/session/shared pooler is not an acceptable workaround for this particular test.

What happens

The Direct PostgreSQL connection reaches the server, but authentication is rejected.

The client receives:

SQLSTATE: 28P01
Classification: invalid_password / password authentication failed

The Supabase Postgres logs independently show:

password authentication failed for user "postgres"

So this does not appear to be only a client-side error classification.

Troubleshooting already performed

1. Confirmed the connection details directly in the Supabase Connect dialog:

   • Direct connection
   • port 5432
   • database postgres
   • user postgres

2. The original network had a connectivity problem with the Direct IPv6 endpoint.

3. I switched the PC to a smartphone tethering connection.

4. On that network, TCP port 5432 to the Direct database endpoint is reachable.

5. TLS initially failed with SELF_SIGNED_CERT_IN_CHAIN.

6. I configured the Supabase Root 2021 CA through NODE_EXTRA_CA_CERTS.

7. After resolving that TLS trust issue, the failure progressed to PostgreSQL authentication.

8. The process-local Direct connection URI was rebuilt from the latest DEV database password using a masked prompt.

9. The password was percent-encoded before constructing the PostgreSQL URI.

10. The resulting connection still fails with PostgreSQL SQLSTATE 28P01.

11. The Supabase Postgres logs show the corresponding password authentication failure for user "postgres".

12. I have already performed two controlled database-password resets for this DEV project. The Direct endpoint continues to reject authentication.

I have not performed a third password reset because repeating the same reset without understanding the persistent 28P01 does not seem useful.

What I would like to understand

Is there any known situation where a database password reset can succeed in the Dashboard but the Direct PostgreSQL endpoint continues to authenticate against a different/stale password state?

Is there any server-side state, role configuration, password propagation issue, or diagnostic available in Supabase that I should check for the postgres role after a password reset?

Are there any additional safe diagnostics that can distinguish a password mismatch from a password-reset propagation/server-side authentication issue without exposing the database password?

Important constraints

• This is a DEV project.
• I do not want to expose credentials or the full connection URI.
• I do not want to repeatedly reset the password without a specific reason.
• I need to test the Direct PostgreSQL endpoint rather than use a pooler as a workaround.

Any guidance on the next diagnostic step would be appreciated.

Thanks.

[BryceEWatson]

I'd start with the server log, because Postgres records why a password login failed and keeps that reason away from the client. It's the safest way to tell a wrong password from a server-side problem without exposing anything.

1. In the dashboard, open Logs, find the "password authentication failed for user postgres" entry and expand it. There should be a DETAIL line with it. Postgres writes one of these: "Password does not match for user", "User has an expired password", "User has no password assigned", or "Role does not exist". Only the first one means the password you're sending differs from the stored one.
2. In the SQL Editor, run select rolname, rolvaliduntil from pg_roles where rolname = 'postgres';. If rolvaliduntil is a date in the past, every login fails with 28P01 however many times you reset the password, because a reset changes the password but not that expiry date. If that's what you find, it's worth adding to your ticket.
3. If the DETAIL says the password doesn't match, take the URI out of the picture for one test: connect with host, port, user and database as separate parameters and let psql prompt for the password. If that works, the problem is in how the URI gets built. Double percent-encoding is an easy one to miss, since a % from the first pass gets encoded again. I'd also check that a PGPASSWORD variable or a .pgpass file isn't quietly supplying an older password.