pg_hba.conf Generator
pg_hba.conf controls who may connect to PostgreSQL, from where, to which database, and how they must authenticate. Get a column wrong and you either lock yourself out or get the classic `no pg_hba.conf entry for host ...` error. This generator builds a properly aligned rule from a connection type, database, role, CIDR address and authentication method, warns about the combinations that silently do not work (peer over TCP, cert without hostssl, replication not matching `all`), and gives you a complete example file plus the SQL to reload and verify it. Everything runs in your browser — nothing is uploaded.
Do more than pg_hba.conf generator — meet Chat2DB
Chat2DB is an AI-powered SQL client for Windows, macOS and Linux. Write SQL in natural language, format and optimize queries automatically, and manage MySQL, PostgreSQL, Oracle and 20+ other databases in one workspace.
How to use
- Choose a preset or set the connection type: local for Unix sockets, host for TCP, hostssl to force encryption.
- Fill in the database, role and client address (CIDR such as 10.0.1.0/24), then pick an authentication method — scram-sha-256 for normal users, peer for local admin.
- Copy the generated line into pg_hba.conf above the broader rules, run SELECT pg_reload_conf(), and check pg_hba_file_rules for parse errors.
Frequently asked questions
Why do I get "no pg_hba.conf entry for host" even though the user and password are correct?
That error is raised before the password is ever checked: PostgreSQL scanned pg_hba.conf top to bottom and found no line whose type, database, user and address all matched your connection. The usual causes are a missing rule for the client's real IP (a NAT gateway or Docker bridge address, not the address you expected), an IPv6 connection (::1) when you only added an IPv4 rule, connecting over TCP when the only rule is `local`, or a `replication` connection that a `host all all` line does not cover. Look at the address in the server log line, add a matching rule, then run SELECT pg_reload_conf().
What is the difference between scram-sha-256, md5, trust and peer?
scram-sha-256 is the modern challenge-response password method and is what you should use for every network connection (PostgreSQL 10+). md5 is the older password hash — still supported, but weaker and only kept for legacy clients. trust skips authentication entirely and lets anyone who can reach the port connect as any role, so it belongs only on a Unix socket or 127.0.0.1 during initial setup. peer asks the operating system for the connecting Unix user's name and requires it to equal the PostgreSQL role name, which is why `sudo -u postgres psql` works with no password but `psql -h localhost -U postgres` does not.
Do I have to restart PostgreSQL after editing pg_hba.conf?
No — a reload is enough. Run SELECT pg_reload_conf() as a superuser, or `sudo systemctl reload postgresql` / `pg_ctl reload`. Existing sessions keep their current authentication; only new connections are evaluated against the new rules. Always verify with SELECT * FROM pg_hba_file_rules, because a syntax error makes the server keep the previous rules and log a complaint you may not notice. If you'd rather manage connections and roles from a GUI, Chat2DB is a free AI-powered SQL client that shows roles, privileges and active sessions in one place — get it at https://chat2db.ai/download or use https://app.chat2db.ai.
