FATAL: password authentication failed

What you see

psql: error: connection to server at "127.0.0.1", port 5432 failed:
FATAL:  password authentication failed for user "postgres"

Node drivers, Prisma and other tools show the same message, sometimes with code 28P01.

Why it happens

The server you reached didn't accept that user name and password. Postgres gives the same message whether the password is wrong or the user doesn't exist, so a typo in the user name looks exactly like a wrong password.

On SupaHost there are three common reasons:

• The password is from somewhere else. After moving from Supabase Cloud or another host, the old database password is still in your .env.
• The user name has a suffix. Supabase Cloud pooler strings use postgres.<project-ref>. On SupaHost the user is plain postgres.
• You're not talking to SupaHost at all. If something on your machine already listens on port 5432 (a local Postgres or a Docker container), the tunnel can't bind that port and your client connects to the local server, which doesn't know your SupaHost password.

How to fix it

1. Copy a fresh connection string from Dashboard → your project → Connect tab → Database → Show connection string (owner only, Business and Enterprise). It looks like:

   postgresql://postgres:<password>@127.0.0.1:5432/p_app_one
   

   Use it as-is. The user is postgres, the host is 127.0.0.1 and the database is p_ plus your project name with hyphens as underscores.

2. Start the tunnel in its own terminal and read its output:

   ssh -N -L 5432:127.0.0.1:5432 [email protected]
   

   If it prints bind [127.0.0.1]:5432: Address already in use, another server owns that port. Forward a different local port instead and change the port in your connection string to match:

   ssh -N -L 55432:127.0.0.1:5432 [email protected]
   psql "postgresql://postgres:<password>@127.0.0.1:55432/p_app_one" -c "select current_database();"
   

3. Check that your app actually loads the value you think it does. Print the host, port, user and database (not the password) at startup. A stale DATABASE_URL in a shell profile or CI secret often wins over .env.

4. If the password contains characters such as @, :, / or #, they must be percent-encoded inside a URL. The string from the dashboard is already safe to paste.

On SupaHost

• To rule out the network and the tunnel, SSH in and run sudo supahost-psql app-one. It opens psql as postgres inside the server without a password. If that works, the problem is on the client side.
• The postgres role belongs to the instance's Postgres server, so every project on the instance uses the same password. Their connection strings differ only in the database name.
• Don't change the password yourself with alter role postgres password .... Studio signs in as the same role, and the connection string in the dashboard would no longer match. If you think the password has leaked, see Resetting a project's database password.
• On Builder and Pro there's no direct Postgres access, so no password to use. Work through the Data API, Studio's SQL editor or MCP execute_sql instead.

Related

• SSH access and direct Postgres
• Connecting directly to Postgres (psql, pg_dump, ORMs)
• Connection refused or timeout when connecting to Postgres
• no pg_hba.conf entry for host