Master Passwordless PostgreSQL Logins: .pgpass, PGPASSWORD, and pg_hba.conf

Introduction

Repeatedly typing a password for psql slows down development and automated workflows. PostgreSQL provides three mechanisms to supply credentials without interactive prompts: a per‑user .pgpass file, the PGPASSWORD environment variable, and server‑side authentication rules in pg_hba.conf.

.pgpass File – User‑Specific Credential Store

File location and format

Create a plain‑text file named .pgpass in the home directory of the operating‑system user that runs psql. Each line must follow the exact syntax: hostname:port:database:username:password Example for a local database:

127.0.0.1:5432:mydatabase:postgres:your_password

Wildcards ( *) can replace any of the first four fields to match multiple hosts, ports, databases, or users. For instance, to apply the same password to any database on the local server for the postgres user:

127.0.0.1:5432:*:postgres:your_password

Permissions

For security, the file must be readable only by its owner. Set the mode to 0600: chmod 600 ~/.pgpass If the permissions are more permissive, psql will ignore the file.

PGPASSWORD Environment Variable – Temporary Credential Supply

How to use

Export the variable in the shell before invoking psql:

export PGPASSWORD='your_password'
psql -h 127.0.0.1 -p 5432 -U postgres -d mydatabase

When the session ends, remove the variable to avoid leaving the password in the environment:

unset PGPASSWORD

Security considerations

The password becomes visible in the shell’s history and may appear in the process list (e.g., ps aux). Therefore this method is suitable only for short‑lived scripts or controlled environments.

Server‑Side Configuration – pg_hba.conf

Purpose

The pg_hba.conf file defines how clients are authenticated. By editing it you can grant password‑less access to all users or to specific roles.

Common authentication methods

trust – Allows any client that can reach the server to connect without a password. Useful for isolated development setups but unsafe for production.

peer – Works for local connections; the operating‑system username must match the PostgreSQL role name.

Example entry enabling trust for local connections

# TYPE  DATABASE  USER      ADDRESS  METHOD
local   all       postgres            trust

After editing, reload the server configuration so the changes take effect (e.g., SELECT pg_reload_conf(); or pg_ctl reload).

Security warning

Using trust opens the server to unauthenticated access. In production environments prefer stronger methods such as md5 or scram-sha-256.

Choosing the Appropriate Method

Use .pgpass when you need a persistent, per‑user solution with proper file permissions. Use PGPASSWORD for short‑lived scripts where creating a file is undesirable. Modify pg_hba.conf only when you require server‑wide password‑less access and can enforce strict network isolation.

Conclusion

Automating PostgreSQL authentication improves productivity. The .pgpass file offers a secure, user‑scoped approach; the PGPASSWORD variable provides a quick, temporary shortcut; and configuring pg_hba.conf gives administrators server‑wide control, albeit with significant security implications. Select the method that matches your workflow and security policy.