Postgres pg_dump vs pg_basebackup: logical dump or physical base backup

pg_dump vs pg_basebackup: the direct answer

pg_dump takes a logical backup: it reads one database through SQL and writes out what is needed to recreate it. pg_basebackup takes a physical backup: it copies the files of the entire running cluster over a replication connection. Use pg_dump when you need portability or a single database. Use pg_basebackup when you need a fast whole-cluster restore, a standby, or point-in-time recovery.

Both commands ship with PostgreSQL, so neither has a plan or a price; the cost is the storage you send the output to. Facts here were checked against the current PostgreSQL documentation on 3 October 2026.

Side-by-side on nine criteria

One thing each does that the other cannot

Only pg_dump can back up part of a cluster and move it across versions. The manual says its output can generally be reloaded into newer PostgreSQL versions and that it is the only method that works when moving to a different architecture, such as 32-bit to 64-bit. With -Fc or -Fd you can later restore a single table.

Only pg_basebackup produces a starting point for WAL replay. The manual is blunt that pg_dump and pg_dumpall cannot be part of a continuous-archiving setup, because logical dumps lack the information WAL replay needs. A base backup can also seed a streaming-replication standby; -R writes the standby settings for you.

Point-in-time recovery needs WAL archiving, not just a base backup

A base backup on its own restores the cluster to the moment the backup finished. By default pg_basebackup streams the WAL generated during the backup (-X stream) so the copy is self-contained, but nothing after that is covered.

To recover to a later moment you must also archive WAL continuously. That means wal_level set to replica or higher, archive_mode = on, and an archive_command, set up and tested before the first base backup. Recovery then restores the base backup, sets a restore_command, creates a recovery.signal file and replays WAL up to the target you choose. The target must be later than the end of the base backup. Dump versus point-in-time recovery covers the decision in more depth.

A typical documented invocation is pg_basebackup -D backup -Ft -z -P, which writes gzip-compressed tar files into the backup directory and shows progress. The target directory must be empty or not yet exist.

Who each command suits

• pg_dump suits databases small enough to dump and restore inside your recovery window, major version upgrades, copying production to staging, and managed platforms that do not grant replication access.
• pg_basebackup suits self-hosted clusters where a day of data loss is unacceptable, large databases where replaying SQL would take too long, and anyone building a standby.
• Both suit a production system that wants minute-level recovery and a portable copy. Run base backups plus WAL for recovery and a regular pg_dump -Fc for portability.

If you choose the physical route for anything beyond one server, look at pgBackRest, Barman or WAL-G, which add retention and WAL management. Postgres backup tools compares them.

What switching from dumps to base backups involves

Moving from pg_dump to pg_basebackup is more than swapping a command. You need a replication-capable role and a pg_hba.conf entry, a WAL archive location with its own monitoring, noticeably more storage for the cluster copy and the WAL, and a new restore procedure that replaces the whole data directory rather than loading into a running server. Your restore runbook has to be rewritten and rehearsed.

Going the other way is simple: pg_dump needs no server changes. On hosted databases where you cannot run pg_basebackup at all, the provider's own snapshots fill the physical role, and a scheduled logical dump, scripted or through a managed service such as SimpleBackups, gives you an independent copy. For a small database with relaxed recovery targets, a tested pg_dump alone is enough.