Session Pooler keeps returning 28P01 after database password resets; Supavisor logs show validation secret refresh followed by upstream postgres auth failure

[DrTrietPham]

I am seeing a persistent Supavisor Session Pooler authentication failure on a managed Supabase Free-plan staging project.

This appears similar to open issue #44210 and the recently closed discussion #48703, but I have additional Supavisor logs and have already ruled out several client/network causes.

Environment

Managed Supabase project, Free plan
Region: ap-northeast-2
Client: Windows, PostgreSQL psql 18
Connection mode: Supavisor Session Pooler
Pooler port: 5432
Database: postgres
Username format: postgres.<PROJECT_REF>
Session Pooler host copied directly from the Dashboard

I am intentionally omitting the complete project ref, password, and connection string from this public post.

Observed problem

Repeated clean psql authentication probes reach the Session Pooler/PostgreSQL path but fail with:

password authentication failed for user "postgres"

The database password has been reset several times from Dashboard → Database Settings. The latest passwords were deliberately simple ASCII alphanumeric strings to eliminate URL-encoding, keyboard-layout, special-character, newline, and clipboard ambiguity.

After the resets I waited before retrying.

Already verified

correct project reference
correct Session Pooler host
correct scoped username postgres.<PROJECT_REF>
port 5432
database postgres
project is Active
no banned IP addresses
no Network Restrictions
TCP connectivity to the Session Pooler succeeds
authentication reaches the server but is rejected
no Supavisor Circuit breaker open condition was detected in the latest controlled probes
the application is not involved; the failure reproduces with psql

Relevant Supavisor logs

Around one of the password-rotation attempts:

SecretChecker not started, using a one-off auth_query connection

ClientHandler: Validation secrets changed, cache updated, deleting upstream auth

immediately followed by:

ClientHandler: Exchange error: password authentication failed for user "postgres"

This is the part that seems unusual to me: Supavisor appears to detect the validation-secret change and invalidate/update its state, but its subsequent upstream authentication as postgres is still rejected.

Direct connection diagnostic

I also tried to determine whether I could bypass Supavisor.

db.<PROJECT_REF>.supabase.co resolves successfully to an IPv6 address, but this Windows host/network has no IPv6 default route:

Get-NetRoute -AddressFamily IPv6 -DestinationPrefix "::/0"

returns no route, and TCP/5432 to the resolved IPv6 address fails.

Therefore I cannot currently perform the direct-Postgres comparison from this network and must use the IPv4 Session Pooler.

Related reports

#44210 — open bug / supavisor issue: password rejected after reset
#48703 — very similar Supavisor validation-secret/upstream-auth log sequence
#47333 — another 28P01-after-password-reset report

Questions

Does the log sequence above indicate a possible desynchronization between the managed postgres role password, project validation secrets, and Supavisor's upstream authentication state?
Is there a supported self-service way to force Supavisor to reload/resynchronize the upstream credential?
Some community replies suggest restarting the project or Pause → Resume. Is that currently a recommended/supported action for this condition on a managed Free project?
If Pause → Resume is appropriate, should the database password be reset again after the project resumes, or should the current password be retained?
Is testing the Transaction Pooler on port 6543 useful for distinguishing a Session-mode problem from a tenant-wide Supavisor credential problem, or would both modes be expected to use the same affected upstream credential state?
Is there any supported diagnostic that can verify the managed postgres role credential state without exposing or rotating the password again?

I have stopped further password resets and connection retries until I understand the correct recovery procedure.

I can provide the complete project ref privately to a Supabase maintainer if needed.

[akashxmohan0099]

This has moved past the usual client-side connection-string mistakes. The useful distinction now is whether the managed postgres role rejected the new password, or Supavisor retained an unusable upstream credential.

I would not use Pause → Resume as the next diagnostic. Supabase documents pausing as a Free-project lifecycle operation, not as a supported Supavisor credential-resync mechanism. It also changes more state than necessary and makes the clean password-rotation timeline harder to reason about.

A bounded test sequence would be:

1. Stop every client and wait a few minutes without rotating again. Supabase's restore documentation explicitly notes that a database-password reset can take a few minutes to take effect, especially after multiple resets.
2. Copy fresh Session (5432) and Transaction (6543) strings from the Dashboard Connect dialog and probe both with the same current password.
3. If both return 28P01, that is strong evidence of a tenant/upstream credential problem rather than something specific to Session mode. Both are Shared Pooler/Supavisor paths; changing ports does not give you a second independent database password.
4. If possible, run one direct db.<ref>.supabase.co:5432 probe from an IPv6-capable network. A successful direct connection plus failure on both pooler ports isolates the problem to Supavisor. The same 28P01 directly would instead indicate that the managed role password itself did not settle as expected.

The current connection guide confirms that direct connections are IPv6 on Free projects, Session mode is Shared Pooler 5432, and Transaction mode is Shared Pooler 6543: https://supabase.com/docs/guides/database/connecting-to-postgres

There is no supported way to read back or verify a managed role's password. The available checks are an authentication attempt or another rotation, and another rotation now would discard useful evidence. Since your log shows the validation secret being refreshed and then an immediate upstream rejection, I would send Supabase Support the private project ref plus the exact reset and probe timestamps and ask them to compare the managed postgres role state with the Supavisor tenant credential.

Also keep all clients stopped while testing. Supabase documents repeated stale-password attempts as capable of extending the Supavisor circuit-breaker window, even though you are not currently seeing that specific error: https://supabase.com/docs/guides/troubleshooting/supavisor-error-circuit-breaker-open-after-password-rotation-0fdb72

So: retain the current password, test both pooler modes once after the propagation window, use a direct IPv6 probe if available, and escalate rather than pausing or rotating again if the controlled tests still fail.

[DrTrietPham]

I am seeing the same failure pattern on a separate Supabase Free-plan staging project.

Both Supavisor modes now reproduce the same authentication error with the current database password:

Session Pooler, port 5432 → FATAL: password authentication failed for user "postgres"
Transaction Pooler, port 6543 → FATAL: password authentication failed for user "postgres"

The database password has been reset multiple times, the project is active, there are no banned IPs or network restrictions, and the connection parameters have been verified.

Relevant Supavisor logs also show:

Validation secrets changed, cache updated, deleting upstream auth

followed by:

Exchange error: password authentication failed for user "postgres"

Full reproduction and timeline are documented here:
https://github.com/orgs/supabase/discussions/49116

Direct PostgreSQL comparison is not available from the current client because the network has no IPv6 default route.

I have stopped further password resets and retries. If this is the same managed Supavisor credential-sync issue, is a managed-side resync required, or is Pause → Resume currently the recommended self-service recovery?

[DrTrietPham]

Update with additional diagnostics and a few precise questions for the Supabase team.

Since my original post:

Session Pooler 5432 and Transaction Pooler 6543 both reject the same current database password with 28P01 for postgres.
Both tests were performed with PostgreSQL psql 18 and the Dashboard-provided pooler parameters.
No further password rotation has been performed.
Direct Postgres comparison is unavailable from this client because the direct endpoint is IPv6-only and this network has no IPv6 default route.

One correction to my earlier wording: all observations are from one Supabase project of mine. I have not tested a second project.

A Supavisor authentication lifecycle also logged:

SecretChecker not started, using a one-off auth_query connection

Validation secrets changed, cache updated, deleting upstream auth

Exchange error: password authentication failed for user "postgres"

I understand from the Supavisor behavior that a validation-secret refresh may occur after the failing exchange and therefore does not retry that same connection. What I cannot determine from the managed deployment is whether subsequent connections are guaranteed to see the refreshed verifier across all nodes.

My remaining questions are:

After Validation secrets changed, cache updated, should subsequent connections be expected to validate against the current verifier from pg_authid, or can managed Supavisor nodes remain inconsistent longer?
Is there a known condition, similar to open issue #44210, where Dashboard password reset reports success but the managed postgres credential state remains inconsistent? Is there a supported managed-side resync/check for this?
Supabase documentation now states that Temporary Access works through the IPv4 shared connection pooler using jit=true. If I authenticate temporarily as postgres and then use PostgreSQL \password postgres, is that a supported recovery procedure on managed Supabase, and will Supabase's managed/control-plane credential state remain consistent with the password changed that way?
If not, what is the recommended recovery path that avoids another blind Dashboard password reset and avoids putting a plaintext password into ALTER ROLE in SQL Editor?

I have stopped further password resets and authentication retries while waiting for guidance.

[aliabbas-muhammadi]

Since you've already ruled out the client-side causes, this narrows to two places the new password can fail to line up, and your Supavisor logs point fairly clearly at one of them:

1. the managed postgres role never actually took the new password, or
2. Supavisor is still handing an old upstream credential to Postgres.

SecretChecker not started, using a one-off auth_query connection followed by Validation secrets changed, cache updated, deleting upstream auth reads like (2): the pooler fell back to a per-connection auth_query instead of a warm secret cache, and it's invalidating the cached upstream credential. If a probe lands while that's mid-swap, you get exactly this 28P01.

Two quick tests split the cases:

A. Hit the direct connection instead of the pooler. Port 5432, host db.<PROJECT_REF>.supabase.co, username plain postgres — drop the postgres.<REF> scoping, that format is pooler-only. (If your project only exposes the pooler — some newer IPv4-deprecated projects do — skip to B.)

• Direct succeeds but the pooler still fails → the role password is correct and the fault is Supavisor holding a stale upstream cred.
• Direct also fails → the reset didn't land on the role. Reset once more and confirm the dashboard shows it committed before probing.

B. Rule out the race. deleting upstream auth is the cache mid-swap; probing in that window gives a transient 28P01. Wait until you see secrets changed, cache updated followed by a clean auth_query line, then retry.

If A comes back direct-good / pooler-bad and it persists past the refresh window (i.e. not just a timing race), that's a Supavisor-side cache that isn't self-healing — worth a support ticket quoting those two log lines rather than pause/resume, which (as @akashxmohan0099 said) changes more state than it fixes.

Which of A's two outcomes do you get? That's the thing that tells us whether it's your role or their pooler.

[mousapouramir53-byte]

I am seeing the same failure pattern on a separate Supabase Free-plan DEV project.

Both Supavisor modes fail with the current database password:

• Session Pooler (5432): PostgreSQL 28P01 / password authentication failed
• Transaction Pooler (6543): PostgreSQL 28P01 / password authentication failed

We have ruled out the usual client-side causes:

• correct Supavisor username format
• correct project reference
• correct ports and database name
• URL parsing and percent-encoding verified
• same password byte-for-byte in both connection URLs
• no whitespace, placeholder, double encoding, or malformed credential text
• DNS/TCP reachability to both pooler endpoints passes
• Network Restrictions are not blocking access
• Prisma and an independent Node pg client both reproduce the same 28P01 error

After the latest password rotation, Pooler Logs show:

Validation secrets changed, cache updated, deleting upstream auth

followed immediately by repeated:

ClientHandler: Exchange error: password authentication failed for user "postgres"

The visible Postgres logs for the same period show normal database activity and no corresponding client authentication error.

Direct Postgres comparison is not currently available from this network because the direct endpoint is not reachable from this client environment.

I have stopped further password resets and retries.

A Supabase Support ticket is already open for this project:
SU-461420

Could a Supabase maintainer confirm whether this pattern can indicate a managed Supavisor/upstream credential synchronization issue after password rotation, and whether a managed-side resync/check is required?

I do not want to perform another blind password reset, Pause/Resume, or ALTER ROLE operation without confirmation.