Managed Supabase database password reset is not accepted by Supavisor/Postgres

[tuyenpham6688]

Hello Supabase team and community,

I am experiencing a production database authentication outage after rotating the database password of a managed Supabase project.

Environment

• Managed Supabase project
• PostgreSQL version observed previously: 17.6
• Prisma Client: 6.19.2
• Backend: long-running NestJS API running in Docker on an IPv4 VPS
• Connection type: Supavisor Session pooler
• Pooler region: ap-southeast-1
• Pooler port: 5432
• Database: postgres
• Username format: postgres.<project-ref>

I have omitted the complete project reference, IP address, password, password fingerprint and connection string because this discussion is public.

Original issue

The application started returning database authentication errors during login.

A read-only Prisma connection test against the existing runtime configuration returned:

PrismaClientInitializationError
Authentication failed

The application health endpoint also reported:

status=error
database=disconnected

Both application containers were then stopped to prevent repeated authentication attempts with stale credentials.

Password reset and secure verification

I reset the project database password using the Supabase Dashboard.

To eliminate clipboard, shell and URL-encoding issues, I performed the following checks:

1. Generated a new 40-character password containing only ASCII letters and numbers.

2. Used exactly that password in the Dashboard reset form.

3. Transferred the password to the VPS through an SCP file rather than terminal paste.

4. Verified the transferred secret by:

   • exact byte length;
   • SHA-256 comparison between the local machine and VPS;
   • strict Base64 decoding;
   • no newline or BOM;
   • single URL-encoding pass.

5. Constructed a new connection URL using:

   • the Session pooler host copied from the Dashboard;
   • port 5432;
   • database postgres;
   • username postgres.<project-ref>;
   • sslmode=require.

The password and URL were never printed.

Network checks

The VPS can resolve and reach the Session pooler successfully:

POOLER_IPV4_DNS_GATE=PASS
POOLER_TCP_GATE=PASS

The Dashboard reports:

There are no banned IP addresses for your project.

The direct database hostname resolves to IPv6, but this VPS does not have functional outbound IPv6:

DIRECT_IPV6_DNS_GATE=PASS
DIRECT_IPV6_TCP_GATE=FAIL

Therefore, the Session pooler is the required connection path for this VPS.

Read-only Prisma probe

A clean Prisma Client instance was created with the candidate connection URL supplied directly through the datasource configuration.

The test attempted only:

SET TRANSACTION READ ONLY;

followed by read-only metadata queries.

The result was:

DATABASE_CONNECT_ATTEMPT=STARTED
DATABASE_PROBE=FAIL
DB_PROBE_CLASSIFICATION=AUTHENTICATION_FAILED
PRISMA_ERROR_NAME=PrismaClientInitializationError

No migrations, schema changes or row mutations were executed.

Relevant Pooler Logs

At the exact time of the failed connection, Pooler Logs showed:

SecretChecker not started, using a one-off auth_query connection
ClientHandler: Validation secrets changed, cache updated, deleting upstream auth
ClientHandler: Exchange error: password authentication failed for user "postgres"

The authentication failure repeated immediately after the validation-secret cache update.

What appears unusual

The log sequence suggests that Supavisor received the validation-secret change and invalidated its cached upstream authentication state, but the subsequent one-off auth_query connection was rejected by the upstream postgres role.

The following have already been verified:

• correct Session pooler host from the Dashboard;
• correct port 5432;
• correct username format;
• correct database name;
• TCP connectivity;
• no network ban;
• no terminal-paste corruption;
• no special characters requiring unusual URL handling;
• no stale application containers making additional attempts;
• exact local/VPS password fingerprint match.

Questions

Could this indicate that the Dashboard password-reset operation updated the project validation secret but did not update, or did not fully synchronize with, the actual password of the upstream PostgreSQL postgres role?

Is there a supported way to verify or force resynchronization between:

1. the managed PostgreSQL postgres role password;
2. the project validation secrets;
3. Supavisor’s upstream authentication state?

Would another password reset be safe, or should this project be repaired by Supabase support before any further attempts?

I have also opened a Supabase support request, but the project is currently handled under Free-plan support priority.

Thank you for any guidance.

[trtajim]

Looks like a Supavisor-side credential sync issue.

The logs show the pooler detected the secret change, but the upstream postgres authentication still failed. Since you already verified the password, URL, network, and Prisma setup, this likely isn't a client-side issue.

A fresh password reset may be worth trying once, but if the same error continues, Supabase support will likely need to resync the database role password and Supavisor auth state.

[cekuu35]

Worth separating three layers before assuming the reset didn't take, because your own pooler log points at a specific one.

The line that matters is:

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

Note the user is postgres, not postgres.<project-ref>. On the Session pooler your client authenticates to Supavisor as postgres.<ref>; Supavisor then authenticates upstream to Postgres as postgres, using the tenant secret it has cached. So that error isn't your client's credential failing the pooler — it's the pooler's own cached upstream secret failing against Postgres after your rotation. The two lines above it fit that reading:

SecretChecker not started, using a one-off auth_query connection
ClientHandler: Validation secrets changed, cache updated, deleting upstream auth

It detected the change and rebuilt the cache, but the upstream auth it then attempted still failed — i.e. the value it refreshed to is not the one that works. That's a pooler-side state problem, not your connection string or Prisma.

Two checks confirm it, both of which take Prisma out of the picture:

1. Hit the pooler with psql, not Prisma:

psql "postgresql://postgres.<ref>:<newpw>@<session-pooler-host>:5432/postgres?sslmode=require"

If this fails with the same auth error, Prisma is exonerated and you have a clean reproduction. If it works, the problem is Prisma-side (usually Session-pooler prepared-statement handling, not auth) and the thread changes.

2. If you can reach a direct connection at all — you noted IPv6 is down on this VPS, but any IPv4-capable box works, even briefly. Direct connections skip Supavisor's secret cache entirely. New password works directly but not through the pooler = the tightest possible proof the cache is the culprit, and the right artifact for the ticket.

If both point at the pooler, the practical unblock is forcing Supavisor to re-read the secret. A project pause/resume sometimes triggers it (heavier than the restart you already tried). Rotating the password once more has also cleared it for some people, presumably by retriggering a clean cache rebuild. And it's worth pushing SU-435660 specifically as "Supavisor upstream auth failing after password rotation, cache not converging" rather than a generic outage — that framing tells them where to look.

One five-second thing to rule out while you're there, since it produces an identical symptom: confirm the live connection string's username still carries the .<project-ref> suffix. A config step that drops it makes you authenticate as bare postgres to the pooler, which fails exactly this way.