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.

[asawaku1632]

Thank you. I completed the suggested checks. 1. The `postgres` role is not expired: `rolname = postgres` `rolvaliduntil = NULL` 2. Unfortunately, I can no longer inspect the DETAIL from the previous 28P01 event because this project is on the Free plan and Unified Logs retains logs for only 1 day. The previously observed Postgres log was: `password authentication failed for user "postgres"` 3. I installed psql 17.11 and performed the test without using a connection URI. I specified the Direct host, port 5432, user `postgres`, and database `postgres` as separate psql parameters and used `-W` so that the current DEV database password was entered interactively. The Direct hostname resolved successfully to IPv6 and psql reached the PostgreSQL server, but authentication still failed: `FATAL: password authentication failed for user "postgres"` Therefore, the failure reproduces without my Node.js connection URI construction and without password percent-encoding. Two controlled database password resets have already been performed for this DEV project, with the same authentication result. Given these results, is there another server-side diagnostic I can perform to determine why the Direct endpoint is rejecting the current `postgres` password? I would prefer not to perform another password reset unless there is a specific diagnostic reason to do so. Thanks. 2026年9月29日(火) 7:00 Bryce Watson ***@***.***>:

…

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. — Reply to this email directly, view it on GitHub <#50970?email_source=notifications&email_token=CDUAC7JYDD74REIDE2LCQGL5RLNRTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBWGQ3TSMJXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18647917>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CDUAC7MGQQQCORO22YOFCJT5RLNRTAVCNFSNUABIKJSXA33TNF2G64TZHMZDCNBVHA3TCOJTHNCGS43DOVZXG2LPNY5TCMBZGA2TAMBWUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CDUAC7MAB3KIXPQVJXNC5LT5RLNRTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBWGQ3TSMJXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/CDUAC7J5XUP7YGKPRVDD3OT5RLNRTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBWGQ3TSMJXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>