Pgpassword Environment Variable
You set the pgpassword environment variable in your shell to pass a Postgres password. The database client reads this value and logs in without asking you to type. Teams often use this method to run backup scripts and build pipelines. It removes manual prompts during automated runs. Still, engineers also use it on laptops to save time during daily work. When that shared role has broad permissions, one leaked variable exposes the whole database. Anyone who reads that shell value gets full contro
Environment Variable: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set the pgpassword environment variable in your shell to pass a Postgres password. The database client reads this value and logs in without asking you to type.
Teams often use this method to run backup scripts and build pipelines. It removes manual prompts during automated runs. Still, engineers also use it on laptops to save time during daily work. When that shared role has broad permissions, one leaked variable exposes the whole database. Anyone who reads that shell value gets full control over the data.
How the pgpassword environment variable works
Postgres client tools rely on a standard client library to handle logins. When you start a client session, the library checks your shell for specific values. If the server asks for a password, the library looks for this variable first. It sends the stored secret straight to the Postgres server over the network.
You can set the value for a single command or export it for your session. If you set it for one command, it disappears right after the command finishes. If you export it, every child process in that terminal can read the secret. When you close the terminal window, the shell clears the value unless you saved it.
Many engineers save the variable inside their shell startup files for daily use. This choice keeps the password on disk in plain text all the time. Any script or tool running under that user account can read the startup file. Local password files offer a safer disk option, as they force strict file permissions.
What native password variables solve and what they leave open
Setting a shell variable solves one practical problem for engineering teams. It lets scripts and tools log in without a human typing at a keyboard. Build jobs, migration tasks, and health checks can run on a schedule without pausing. For quick local tests, it also stops repeated prompts when you open many sessions.
Environment Variable: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Still, thePostgres docs warns against using this variable on shared or production machines. On many operating systems, other users can inspect the variables of running processes. Crash dumps, debug logs, and monitoring agents also capture process variables by default. Your database password ends up stored in plain text inside third-party log systems.
Even when you secure the host, a static password only checks who logs in. Once the session starts, the database grants the full power of that Postgres role. The login setup cannot inspect individual SQL statements while they run in flight. It cannot block a destructive drop table command or rewrite sensitive fields in query results. If a script or engineer runs a broad select, raw emails and card numbers return.
Sharing one role across multiple scripts makes audit logs very hard to read. The database log shows the role name, not the person who exported the variable. Teams also struggle to rotate the secret when it sits in dozens of pipelines. Updating the password breaks every script until you update each machine by hand.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Why does Postgres warn against using the password variable?
Some operating systems let local users read the variables of other running processes. Build logs and error reports also capture shell variables and expose your password.
What happens if both a password variable and a password file exist?
The Postgres client library checks the shell variable before it looks at the local file. If you set the variable, the client uses it and ignores the file entry.
Why is my password variable ignored during login?
The server might use a trust or peer rule that skips password checks. Also, if you forget to export the variable, child processes will not see it.