Postgres pg_dump vs pg_dumpall: one database or the whole cluster

pg_dump vs pg_dumpall: the difference in two sentences

pg_dump backs up a single database and can write archive formats that pg_restore reads. pg_dumpall backs up every database in the cluster into one SQL script and also saves the global objects that pg_dump skips: roles, tablespaces and privilege grants for configuration parameters.

Both are part of the PostgreSQL distribution, so there is no plan or price to compare for either; they come with the database at no extra charge. This comparison was checked against the current PostgreSQL documentation on 3 October 2026.

Side-by-side on eight criteria

One thing each does that the other does not

Only pg_dump produces the custom and directory archives. Those are compressed by default, can be restored in parallel with pg_restore -j, and let you restore one table instead of everything. The documented examples are pg_dump -Fc mydb > db.dump and pg_dump -Fd mydb -j 5 -f dumpdir.

Only pg_dumpall captures cluster-wide objects. It works by writing commands to recreate roles, tablespaces and empty databases, then calling pg_dump for each database. It also has switches for just the global part: --globals-only (roles and tablespaces), --roles-only and --tablespaces-only. The option --no-role-passwords leaves role passwords out of the script.

Who each command suits

• pg_dump suits single-database backups: one application database, anything large enough to need compression or parallel restore, and migrations of a single database between servers.
• pg_dumpall suits small clusters where one script for everything is convenient, and full-cluster moves to a new server or major version where you want roles and all databases together.
• Both together suit any team that dumps databases one at a time. The PostgreSQL manual states that running pg_dumpall --globals-only is necessary to fully back up the cluster when you run pg_dump on individual databases.

The combined routine is two commands per run:

pg_dumpall --globals-only > globals.sql

pg_dump -Fc mydb > db.dump

Neither command gives point-in-time recovery. If that is the requirement, read pg_dump versus pg_basebackup next.

Restoring each one, and a trap with passwords

A pg_dumpall script is restored with psql -X -f db.out -d postgres. The manual says it does not matter which database you connect to, because the script creates and connects to each database itself, unless you used --clean, in which case connect to postgres.

A pg_dump archive is restored with pg_restore -d newdb db.dump into a database created with createdb -T template0 newdb. Restore globals.sql first so that the owning roles exist. The full sequence is in how to back up and restore a Postgres database.

The trap: pg_dumpall connects once per database and asks for a password each time under password authentication. In a scheduled job that means a hang. The manual recommends a ~/.pgpass file. Also remember that a globals file contains role definitions and, unless you pass --no-role-passwords, the roles' stored passwords, so store it as carefully as the data.

What switching from pg_dumpall to per-database pg_dump involves

A team that starts with one nightly pg_dumpall may want to switch once the script grows too large to restore comfortably. Switching involves three changes. Replace the single command with a loop that runs pg_dump -Fc for each database plus one pg_dumpall --globals-only. Change the restore procedure from psql to pg_restore, with the globals restored first. And update the restore runbook and retention rules, because you now have several files per night instead of one.

If maintaining that loop is the problem, a managed service such as SimpleBackups runs one job per database for you; whether its jobs also capture roles was not stated on the pages read, so confirm that in a test restore. For a single small cluster, the native commands are enough.