error received from server in SCRAM exchange: Wrong password is not an instruction to reset the password. It means PostgreSQL rejected the connection data supplied by one production process. If one deployment contains an old DATABASE_URL, you can often fix it by replacing that secret and retesting the failed sign-in or checkout. If several processes share the database role, or payments succeeded while database writes failed, the repair must also find every outdated connection and account for missed operations.
Every platform claim below was checked against Supabase documentation on 2026-10-02. App Rescue Desk is independent and is not affiliated with Supabase.
TL;DR
- Find the deployment that handled the first failed request. Record the source of its production connection string.
- Copy the connection string from Supabase. Direct and shared-pooler connections use different hosts and usernames.
- A password that works in a form can still fail inside
DATABASE_URLwhen reserved characters are not percent-encoded. - A direct connection that works after rotation, followed by a brief pooler failure, supports a cached-password cause.
- Stop automatic retries if the message changes to
connection refusedorCircuit breaker open.
What does the SCRAM wrong-password message prove?
A Node.js database client or PostgreSQL tool can report:
error received from server in SCRAM exchange: Wrong passwordPostgreSQL can state the same authentication result as:
FATAL: password authentication failed for user "postgres"
SQLSTATE 28P01SCRAM is the password-authentication exchange between a database client and PostgreSQL. These messages prove that authentication did not complete. They do not identify the rejected input or the process that supplied it.
An old connection string and a malformed URI look the same at this stage. The shared pooler can also reject a valid password when the connection uses the wrong username. Resetting the database password addresses none of those causes.
Supabase’s password authentication guide tells readers to check the username before the password. The same guide documents SQLSTATE 28P01, reserved-character encoding and shared-pooler behavior after rotation.
Why can the correct password fail after a deploy?
A deploy can trigger this error even when the database password has not changed. The new process can read DATABASE_URL from a different environment or Supabase project.
Use timing as evidence, not as a conclusion. If the last success used deployment A and the first failure used deployment B, compare their connection-string sources. Then match the database error time to deployment B. Timing alone does not prove that the deploy caused the failure.
The web server and a background worker can read different secrets. Redeploying one does not update the other. A dashboard edit also leaves a running process unchanged until the hosting platform restarts or redeploys it. If production still uses the old value, follow the production environment-variable check before rotating credentials.
Do not expose the full connection string while comparing environments. It contains the database password. The security page explains what evidence to send to the desk.
Is DATABASE_URL stale or malformed?
Compare the connection-string source in the first failed deployment with the last successful deployment.
- Record the last successful request time.
- Record the first failed request time.
- Record the deployment ID for each request.
- Identify which service reads
DATABASE_URL. - Open the Supabase Connect dialog.
- Select the connection mode used by that service.
- Copy the complete connection string.
- Replace only the password placeholder.
- Restart or redeploy only the affected service.
- Test one owned production flow.
Do not paste the connection string into an issue or browser log. Record only the host, port, username pattern and secret version.
A URI must percent-encode reserved characters such as &, #, ? and spaces. A database tool accepts the literal password in a password field. A URI parser treats the same characters as URI syntax inside DATABASE_URL.
This evidence pattern supports an encoding error:
| Evidence | Interpretation |
|---|---|
| The password works in a separate password field | The database accepts that credential through that client |
| The URI fails with the same characters | URI parsing or a different endpoint remains in scope |
| The password contains reserved characters | Missing percent-encoding is strongly supported |
| The URI still fails after correct encoding | Encoding alone does not explain the incident |
Supabase documents the connection-string steps and endpoint differences in Connect to your database.
Are the host, port and username for the correct connection mode?
Supabase provides more than one database endpoint. The correct choice depends on where the code runs.
| Runtime or task | Connection path | Identity detail |
|---|---|---|
| Browser frontend | Data API and client library | Do not put a database connection string in browser files |
| Persistent backend with IPv6 or the IPv4 add-on | Direct connection | Username is postgres for the built-in role |
| IPv4-only persistent backend | Shared session pooler | Username includes the project reference |
| Serverless or edge runtime | Shared transaction pooler | Username includes the project reference |
| Migration, dump or restore | Direct connection | Use the documented direct endpoint when reachable |
Direct connections use a db.[PROJECT-REF].supabase.co host. Shared-pooler connections use the pooler host from the dashboard. The built-in shared-pooler username is postgres.[PROJECT-REF], not only postgres.
Do not construct the pooler host from the region name. Supabase states that the numeric pooler index is not predictable. Copy the host, port and username together from the Connect dialog.
The shared pooler reports a host or username mismatch with a different message:
Tenant or user not foundSupabase’s tenant or user guide says the shared pooler returns this message when it cannot match the host and username to a project. This evidence supports a host or username mismatch, not another password reset.
Did password rotation leave old application instances running?
Password rotation changes the accepted database password at a specific time. Every running process that uses the database role must load the new value.
One successful redeploy proves only that its new process started. An older worker or preview deployment can continue reconnecting with the old password while the new process connects successfully.
Use this order after a password change:
- Stop processes that still use the old password.
- Record which secret version each process loads.
- Test the new password through a direct connection when available.
- Retry the shared pooler a limited number of times.
- Restart only processes that contain the new password.
Supabase documents a brief shared-pooler password cache after a role password changes. If the direct connection succeeds and the pooler fails briefly, the cache explanation is supported. If the direct connection fails, check the connection string again.
The password-rotation troubleshooting guide warns against repeated rotations. Each rotation forces every process to load another password. It also makes each failure harder to match to a password.
Why did the message change to connection refused?
Repeated authentication failures can replace the original message with a temporary connection block.
If the database failure stops a backend or function from answering, users may see a gateway error instead of the database message. The 502 Bad Gateway after deploy diagnosis shows how to connect the public response to the matching backend log without assuming that both messages have the same cause.
Direct or dedicated connections can begin returning:
connect ECONNREFUSED 203.0.113.10:5432The shared pooler can return:
FATAL: Circuit breaker openWhen either message follows repeated wrong-password attempts, stop every process that is retrying. More retries can extend the interruption.
Supabase’s connection-refused guide documents temporary IP bans after repeated authentication failures. Its circuit-breaker guide describes the shared-pooler block and the need to stop clients with outdated credentials.
If authentication failures came first, the changed message supports a temporary connection block. It does not prove a general Supabase outage. Check the project status and database logs before opening a separate investigation.
What evidence should you collect before another deploy?
Collect evidence from one failed request. Do not create repeated customer actions to reproduce the error.
| Evidence | What it can establish | What it cannot establish |
|---|---|---|
| Last success and first failure | The incident window | Which change caused it |
| Deployment ID | Which code and configuration version ran | The secret value loaded at runtime |
| Host, port and username pattern | The selected endpoint and connection mode | Whether the password is correct |
| Secret version or update time | Which password should be active | Whether every process loaded it |
| Exact database error and timestamp | The failed authentication stage | The business records affected |
| One owned test result | Whether the repaired path completes now | Whether earlier failed work ran later |
Record the database operation behind the failed request. A failed read has a different recovery task from a failed payment write. Repairing the connection restores future attempts; it does not run work missed during the incident.
For a Lovable app moved to external hosting, keep connection repair separate from deciding whether the migration is complete. The six-layer migration guide explains why a working repository does not prove that runtime configuration and operations moved with it.
What does a self-service fix look like?
Consider one narrow case. Only the web process fails. Its hosting secret still contains the connection string from before the database password changed. No worker uses the same database role, and no payment or account write failed during the interval.
- Copy the correct connection string from Supabase.
- Update the web process secret.
- Deploy the web process once.
- Test the exact action that failed.
- Check that the authentication errors stopped.
If the test passes and no other process logs the error, the evidence supports one stale DATABASE_URL. This is a reasonable self-service repair. Keep the old deployment available until the test passes.
When does this need a bug-fixing service?
Use a one-off production repair when you cannot name every process that uses the database role. The same applies when repeated attempts have triggered a connection block or the failed period includes payments and account access.
Updating one secret can restore the web process while an old worker continues to fail. A successful test also does not show whether missed database operations ran later. The repair must find every process, stop outdated connections, restore access and test the original workflow. It must then account for missed operations.
The bug-fixing service covers that defined repair. It does not add features or turn the incident into an open-ended migration.
What should happen next?
This article cannot show which password your production processes loaded or account for database operations missed during the failure. If a live workflow now fails with one of these errors, send the failure window and exact message through start a bug fix. The work begins with scope and price agreed before anything in production changes.