no pg_hba.conf entry for host

What "no pg_hba.conf entry for host" means, why SupaHost's own Postgres shouldn't return it, and how to find the server that does (often a local Postgres or your previous host).

What you see

FATAL:  28000: no pg_hba.conf entry for host "198.51.100.23", user "postgres", database "p_app_one", no encryption

The last part varies (no encryption, SSL encryption or GSS encryption) depending on how the client connected.

Why it happens

pg_hba.conf is the server's list of who may connect from where, and how they must prove who they are. Postgres reads it top to bottom and uses the first line that matches the client's address, user, database and connection type. If no line matches, it refuses the connection with this error before checking any password.

You'll mostly see it in two situations:

The server only allows encrypted connections (hostssl lines) and your client connected without SSL.
The server only allows certain IP addresses and yours isn't one of them.

Why SupaHost probably isn't the server saying it

SupaHost manages pg_hba.conf for you, and you can't edit it. Its rules accept password sign-in (scram-sha-256) from any address, encrypted or not, and Postgres itself is only reachable through the SSH tunnel on Business and Enterprise. So when you connect through the tunnel, there's always a matching line. A wrong password gives password authentication failed, not this error.

If you see it, your client is almost always talking to a different server.

How to fix it

Check for a local Postgres on the same port. If something on your machine already listens on 5432, ssh -L 5432:... can't bind it and prints Address already in use, and your client reaches the local server instead. Forward a free port:
```
ssh -N -L 55432:127.0.0.1:5432 [email protected]
```
Then connect with port 55432:
```
psql "postgresql://postgres:<password>@127.0.0.1:55432/p_app_one" -c "select current_database();"
```
The query should print p_app_one.
Check your connection string. A DATABASE_URL that still points at your previous host (Supabase Cloud, RDS, Heroku and so on) gets that host's rules. Copy the SupaHost string from Dashboard → your project → Connect tab → Database → Show connection string.
If you meant to reach another provider (for example running pg_dump against your old database before moving), follow that provider's rules. Usually that means adding sslmode=require to the connection string, or adding your IP to its allow list:
```
pg_dump "postgresql://user:[email protected]:5432/app?sslmode=require" -Fc -f app.dump
```
Confirm which server answered. Once connected, run:
```
select inet_server_addr(), inet_server_port(), current_database(), version();
```
Through the SupaHost tunnel, the database is p_<project> and the version is Postgres 17.

On SupaHost

To check the database itself, SSH in and run sudo supahost-psql app-one, or use Studio's SQL editor. If those work and your local client doesn't, the problem is between your client and the tunnel.
Importing from Supabase Cloud through Dashboard → your project → Import tab needs the Session pooler string (port 5432, user postgres.<ref>), not the direct db.<ref>.supabase.co host.

Updated 11 November 2026 · View as Markdown · Something wrong or missing? Tell us