Fresh database password rejected by both Supavisor Session and Transaction Poolers — SQLSTATE 28P01

[s2e-services]

Hi Supabase team,

I am experiencing a persistent database authentication issue on a Supabase project after multiple controlled database password resets.

I also have an open Supabase support ticket for this issue.

Environment

Region: Southeast Asia (Singapore)
Supabase CLI: 2.113.0

For privacy, I have redacted the exact project reference and internal migration identifiers from this public post.

Problem

A freshly reset database password is being rejected by both Supavisor connection modes with:

FATAL: password authentication failed for user "postgres" (SQLSTATE 28P01)

The database password was reset from:

Dashboard → Database → Settings → Reset database password

For the final controlled test, I used a newly generated password, saved/copied it directly, waited more than 10 minutes after the reset, and entered it twice locally to confirm both entries were identical.

The password was still rejected.

Session Pooler test

Host:

aws-0-ap-southeast-1.pooler.supabase.com

Port:

5432

User format:

postgres.<PROJECT_REF>

Database:

postgres

Result:

FATAL: password authentication failed for user "postgres" (SQLSTATE 28P01)

Transaction Pooler test

Same pooler host and project-scoped username, but port:

6543

TCP connectivity to port 6543 succeeds.

Result:

FATAL: password authentication failed for user "postgres" (SQLSTATE 28P01)

So both Session Pooler and Transaction Pooler are reachable, but both reject the same freshly reset database password.

Other diagnostics already completed

• Supabase CLI can see the correct project through the Management API.
• The local repository is linked to the intended project.
• supabase link --project-ref <PROJECT_REF> completes successfully.
• A subsequent migration list --linked still returns SQLSTATE 28P01.
• Network bans:
  []
• Allowed IPv4 CIDRs:
  0.0.0.0/0
• Allowed IPv6 CIDRs:
  ::/0
• Session Pooler DNS resolves successfully.
• Transaction Pooler TCP/6543 is reachable.
• Direct Postgres hostname has a valid AAAA record.
• Direct IPv6 TCP/5432 is not reachable from the ISPs/networks currently available to me, so I cannot independently test the password against the direct Postgres endpoint.
• No circuit-breaker error is being returned.
• The error is specifically SQLSTATE 28P01.

Earlier CLI symptom

Before switching to explicit password authentication, a linked db push attempt failed before migration execution with:

FATAL: (EAUTHQUERY) unsupported or invalid secret format (SQLSTATE XX000)

The migration was not applied.

After that failure, I switched to explicit SUPABASE_DB_PASSWORD authentication for diagnosis.

All controlled password-auth tests against the reachable poolers have returned SQLSTATE 28P01.

Migration safety

There is one pending local migration.

It remains unapplied.

No further real database pushes are being attempted while this authentication issue is unresolved.

Related Supabase discussion

I reviewed Discussion #17817 regarding IPv4 deprecation and Supavisor.

My environment cannot currently reach the direct IPv6 database endpoint, so Supavisor is the appropriate IPv4-compatible path.

However, both Supavisor Session Pooler 5432 and Transaction Pooler 6543 are reachable and reject the freshly reset database password.

Question

Could someone from Supabase please advise whether this could indicate:

1. the postgres role credential is not synchronized with the password set in Dashboard;
2. stale Supavisor credential/cache state after password rotation;
3. a project-specific authentication issue affecting both pooler modes; or
4. another required credential/reset step that I may be missing?

If a Supabase maintainer can inspect the project-side PostgreSQL/Supavisor credential state, that would be very helpful.

I have stopped further password resets and authentication retries for now to avoid creating additional noise or triggering temporary authentication blocks.

Thank you.

[s2e-services]

Resolved: The database password was valid. The issue was caused by our local Windows PowerShell 5.1 hidden-input method altering/not correctly receiving pasted credentials. Capturing the password directly from the clipboard and supplying it through SUPABASE_DB_PASSWORD restored normal Supabase CLI authentication. This was not ultimately a Supabase credential synchronization issue.