It fails before the password
Postgres checks host-based auth (pg_hba.conf) first: is a connection from this address, for this user and database, with this method, even allowed? Only if a rule matches does it move on to the password. This error means no rule matched - so the fix is about how and from where you connect, not your credentials.
# the most common fix - the server wants SSL and you did not offer it:
DATABASE_URL=postgres://user:pass@host:5432/db?sslmode=require
# node-postgres equivalent:
new Pool({ connectionString, ssl: { rejectUnauthorized: false } })The two causes
SSL required, none offered
RDS, Supabase, Neon and most managed Postgres reject plaintext connections. Add sslmode=require to the connection string.
Your IP is not allowed
The connecting address is not in the allowlist (managed) or pg_hba.conf (self-hosted). Add the production egress IP.
Where to make the change
On a managed database you do not edit pg_hba.conf directly - you add sslmode=require on the client side and allowlist the IP in the provider console. On a self-hosted Postgres you edit pg_hba.conf to add a scoped rule (host, db, user, address, method) and reload. Either way, the principle is the same: the database is enforcing a front-door policy, and the fix is to satisfy it deliberately - not to widen it to everything.
Get the connection string right with the DATABASE_URL builder (it sets sslmode for you). If the password really is wrong, that is a different error.
See service health while you fix database access
Infraveil brings managed service health, process status, logs, and release controls into one operating view on your servers. Use that context to identify the application affected by a database connection failure while you fix its Postgres access rules. The database administrator or hosting provider still configures pg_hba.conf, SSL, and database network access.
Frequently asked questions
How is this different from “password authentication failed”?
Different layers. The pg_hba error fails first - no rule even permits a connection from your address/method, so it never checks the password. 28P01 means a rule matched and let you try, but the password was wrong. With the pg_hba error, fix how/where you connect, not the password.
What sslmode should I use for a managed database?
At least sslmode=require for RDS/Supabase/Neon - they reject non-SSL connections. require encrypts but does not verify the cert; verify-full also checks it against a CA and hostname. Start with require to connect, then move to verify-full where you can supply the CA.
It connects locally but not from production - why?
Your local machine is likely allowlisted and the production host is not. Managed providers restrict which IPs may connect; a new server or region is blocked until added. Allowlist the production egress IP (or use the provider's VPC/peering).
How do I fix it on self-hosted Postgres?
Add a scoped pg_hba.conf line (host, db, user, address, method like scram-sha-256), match SSL settings, then reload (SELECT pg_reload_conf();). Scope each rule to the smallest address range and strongest method that works - never 0.0.0.0/0 trust.
Client-side, no signup — they run in your browser.