How to Fix the Command “pg_dump not found” Error in PostgreSQL

When working with PostgreSQL in your development projects, you may encounter the frustrating “pg_dump not found” error message preventing you from exporting PostgreSQL database backups using the pg_dump command.

This beginner’s guide will walk through what’s causing this error and the various solutions to correctly configure your PATH environment so pg_dump runs without issues on Linux, MacOS or Windows systems. We’ll also cover alternative methods to backup PostgreSQL databases using GUI tools.

Whether you’re a new developer getting tripped up by environment configuration issues or a seasoned pro encountering PostgreSQL for the first time, these tips will help get you oriented with basic database administration tasks. Let’s get started demystifying and resolving this common pg_dump error.

What Causes the Command “pg_dump not found” Error?

The pg_dump command line program is installed automatically with all PostgreSQL database implementations to facilitate backup and restoration jobs.

Seeing the error “pg_dump not found” means your operating system cannot locate the installed pg_dump application properly to run it. This typically boils down to PATH environment variables not pointing towards the PostgreSQL executable programs directory.

Without the full valid file system path configured, your OS fails to see the availability of pg_dump even though PostgreSQL resides on your computer. Modifying PATH appropriately will resolve this accessibility issue in most cases.

But first, let’s breakdown the exact functionality of PATH and how PostgreSQL as well as other software get linked into it for easy execution from any location.

Understanding the Operating System PATH Variable

The PATH environment variable contains a list of absolute directory paths on a computer that the operating system searches through systematically to locate executable programs.

Without PATH configured correctly, apps won’t execute because the OS fails to find them even if accurately typed at the command line. PATH provides the reference mapping that connects program names like pg_dump to actual binaries on disk.

Here’s a snippet showing the structure of PATH on a Linux machine:


And similarly on Windows:

C:\Program Files\PostgreSQL\14\bin;C:\Program Files\Common Files\Oracle\Java\javapath;C:\WINDOWS\system32;

Each path is separated by a colon (:) on Linux/macOS vs a semicolon (;) on Windows. This serves as the lookup list when commands get invoked in terminal/PowerShell.

When installing program suites like PostgreSQL, it’s common to have their binary folders like /usr/local/pgsql/bin appended automatically to your account’s PATH for convenience.

But sometimes that integration fails or your PostgreSQL tools are inheriting PATH from a system location that hasn’t been updated. In those cases pg_dump and other commands rightfully trigger “not found” errors.

Fortunately, the remedy is adjusting your PATH appropriately to include the folder holding pg_dump.

Next we’ll cover specific techniques and commands to accomplish this on Mac, Linux and Windows computers to stop the errors in their tracks.

How to Update PATH to Fix “pg_dump not found” Errors

Updating your account’s PATH environment variable only takes a few minutes. Apply the steps below for your operating system:


  1. Open terminal and locate your PostgreSQL binaries path. Common default places are:/usr/local/pgsql/bin /usr/lib/postgresql/X.X/bin /usr/bin Substitute X.X for your locally installed PostgreSQL version.
  2. Identify a suitable path based on above search.
  3. Edit (or create) a .bash_profile file in your user home directory:vi ~/.bash_profile
  4. Add this line with pgsql binary path from Step 1:export PATH=/usr/local/pgsql/bin:$PATH
  5. Save and close the file.
  6. Run this command to apply the changes:source ~/.bash_profile

Now PostgreSQL tools like pg_dump should work properly from any location!


  1. Hit Windows key and search for “Environment Variables”
  2. Choose “Edit the system environment variables”
  3. Click the “Environment Variables” button
  4. Under “System Variables” scroll to PATH and double click to edit
  5. Append a new path with the ; delimited PostgreSQL tool location at END of value string:C:\Program Files\PostgreSQL\14\bin
  6. Click OK on all open dialogs to save the updated PATH value
  7. Close and re-open any Command Prompt/PowerShell terminals then retry pg_dump.

With an updated Windows PATH integrating the PostgreSQL installation, pg_dump and other pgsql programs should now be locatable and runnable from the command line.

Permanent vs Temporary PATH Amendments

The PATH modifications shown above span across terminal sessions meaning they persist rebooting your machine. This system-wide change enables all console programs to find PostgreSQL.

Alternatively, you can temporarily amend PATH for just a single terminal. This is great for testing fixes before applying them globally:


export PATH=/usr/local/pgsql/bin/:$PATH


SET PATH=C:\Program Files\PostgreSQL\14\bin;%PATH%

However, single terminal PATH edits disappear when closing that window. For permanent ubiquitous availability of pgsql tools, modify your .bash_profile or System Variables instead.

Alternative PostgreSQL Backup Solutions

If adjusting PATH configuration still fails to expose pg_dump, several backup alternatives exist for mitigating the error:

pgAdmin GUI Tool

pgAdmin provides a popular graphical interface for managing PostgreSQL instances. It comes packaged with most database server installations.

Follow these steps to use pgAdmin for backups instead of pg_dump at the command line:

  1. Launch pgAdmin and connect to your database server
  2. Right click on the registered server under “Servers” and choose “Backup…”
  3. Configure backup file location, format (custom, tar, plain text) plus other options
  4. Click “Backup” button to export a copy of the PostgreSQL database

This intuitive point-and-click process handles backup duties without relying on fussy PATH environment variables hampering pg_dump execution.

Automated SaaS Backups

Several PostgreSQL backup services exist for simply scheduling reliable server exports to the cloud should on-premise solutions fail you. These options backup your database automatically based on schedules and retention policies you configure without any PATH or dump command rigor.

Examples of automated PostgreSQL backup services include:

Tools like these integrate backups directly from PostgreSQL to S3 buckets or other cloud storage providers. Once configured, your database gets exported off-server per your defined rhythm without worrying about PATH issues on the live database host.

Containerization Options

Docker containerization platforms like AWS Elastic Container Service (ECS) provide alternative methods to deploy PostgreSQL services. Containerized instances often include backup tooling covering duties typically performed by pg_dump.

For example, AWS RDS for PostgreSQL builds native backup functionality into its managed database containers. This allows simple point-and-click database snapshot generation and automation.

Evaluating containerized solutions may serve as a rapid fix benefiting from integrated backups should your direct database server host setup cause PATH issues blocking pg_dump functionality.

Troubleshooting PostgreSQL and pg_dump

Here are some other quick tips for troubleshooting “pg_dump not found” errors and restoring database backup capabilities:

  • Double check that a valid PostgreSQL installation exists on your system before pursuing PATH issues. Use postoperative tools like psql -V and services checks to validate it’s present and running.
  • Confirm you have permissions to access the pg_dump application binary and/or perform database backups depending on your operating system and security policies.
  • Manually test that pg_dump operates properly by invoking it with the full path like /usr/bin/pg_dump mydatabase, substituting your valid dumped location. This helps identify issues stemming from missing PATH entries vs possible permission problems or malfunctioning binaries.
  • Scan through PostgreSQL log files after attempted failed dumps for additional context on what’s occurring behind the scenes. Look for permissions errors, collisions with older versions, etc.
  • Search community resources like Stack Overflow to see if other users have encountered and resolved the specific “pg_dump not found” error message you see. Community tips can provide version-specific fixes.

And if all else fails – upgrade to the latest PostgreSQL version! Many tweaks and improvements that correct pesky issues arise with each new release.


Dealing with “command not found” errors in PostgreSQL can quickly get frustrating, especially for newcomers still orienting themselves with database administration responsibilities and OS environment complexities.

Hopefully this guide provided a comprehensive overview of what causes the common pg_dump “not found” error along with various solutions for reinstating PostgreSQL backup functionality – whether by fixing PATH variables to locate the pg_dump tool properly or embracing alternate graphical and cloud backup techniques.

With PATH appropriately configured or substitute backup solutions utilized, developers can resume regularly archiving critical PostgreSQL data stores off-instance to facilitate restoration in the event of crashes, data corruption, or disaster scenarios.

Regular PostgreSQL database dumps also enable migrating data between versions or testing against real-world copies easily within local development environments. Losing the ability to create backups introduces risk across many scenarios.

Regaining pg_dump flexibility or shifting to alternatives like pgAdmin or hosted cloud backup services covers your PostgreSQL instances against data loss while eliminating frustrating errors. Implement a recurring export strategy that best meets your use case so precious database contents stay protected.

Leave a Comment