Best PostgreSQL backup tools in 2026

Use pg_dump when you need a portable logical backup. For a self-managed production database that needs point-in-time recovery, start with pgBackRest. Choose Barman when one backup service manages several PostgreSQL servers, and WAL-G when object storage is the center of a cloud-native recovery workflow.

The best tool is the one that meets a written recovery point objective and recovery time objective in a restore drill. A successful backup job is not proof that the database is recoverable.

PostgreSQL backup tools compared

Choose from the restore backward

A backup decision begins with two numbers. The recovery point objective, or RPO, is the maximum acceptable data loss. The recovery time objective, or RTO, is the maximum acceptable time to return the service to operation. A nightly dump can lose most of a day's work. Base backups plus continuous WAL archiving can recover to a much narrower point, but the restore path is more involved.

Use pg_dump for portability

pg_dump creates a logical backup of one database. The custom and directory formats work with pg_restore, support selective restore, and can parallelize parts of the restore. pg_dumpall can capture cluster-wide objects such as roles, but it produces a plain SQL script.

pg_dump --format=custom --file=app.dump "$DATABASE_URL"
createdb restored_app
pg_restore --dbname=restored_app --jobs=4 app.dump

A dump does not provide point-in-time recovery. It is still valuable as a portable copy that is independent of a cloud provider's snapshot format. For installation, version matching, compressed output, and common errors, use the pg_dump and pg_restore guide for Mac.

Use pg_basebackup as a physical foundation

pg_basebackup takes a physical base backup from a running PostgreSQL cluster through the replication protocol. It is useful for replicas and for teams building their own physical backup process. By itself it does not schedule jobs, enforce retention, monitor failures, or manage a complete archive.

pg_basebackup \
  --host=db.internal \
  --username=replication_user \
  --pgdata=/backups/base-2026-08-11 \
  --format=plain \
  --wal-method=stream \
  --progress

Use pgBackRest for a self-managed production cluster

pgBackRest supports full, differential, and incremental backups, parallel backup and restore, repository retention, verification, and WAL archiving. It is a strong default when a team operates PostgreSQL itself and needs a documented PITR workflow. Its configuration belongs in infrastructure code, and the restore command should be exercised away from production.

Read the pgBackRest user guide for the exact stanza, repository, retention, archive, and restore settings supported by the installed version.

Use Barman for a fleet

Barman runs as a separate backup-management service and can coordinate backups and WAL archives for multiple PostgreSQL servers. That separation is useful when a database team wants one place for backup policy, status, and recovery operations. The tradeoff is another operational service with its own storage, permissions, monitoring, and upgrade path.

Use WAL-G around object storage

WAL-G is a command-line backup and WAL archival tool with support for several object-storage backends. It suits container and cloud environments where credentials, schedules, retention, and restore automation already live in deployment tooling. Keep the complete recovery procedure beside the configuration; a short backup command can hide a long restore dependency chain.

Managed backups still need an exit path

A managed provider can automate snapshots, WAL retention, failover, and point-in-time restore. Verify those controls for the exact plan and region. Test how long a restore takes, whether it creates a new instance, which credentials change, and how the application is redirected. The managed PostgreSQL hosting comparison lists the operational questions to ask before choosing a service.

Keep a periodic logical export when portability matters. Provider recovery protects availability inside that platform; a logical dump protects a different requirement: the ability to inspect or move the data with standard PostgreSQL tools.

A minimum viable production policy

1. Write down the RPO and RTO with the application owner.
2. Choose physical backup and WAL retention that satisfy the RPO.
3. Keep backup credentials separate from database credentials.
4. Store a copy outside the database host and failure boundary.
5. Encrypt the storage and restrict who can restore or delete it.
6. Alert on missed backups, archive failures, and repository capacity.
7. Run a scheduled restore into an isolated environment.
8. Record restore duration and validate important tables and queries.

Restore drill checklist

• Restore without access to the original database host.
• Use credentials available to the on-call engineer.
• Confirm the target PostgreSQL version and required extensions.
• Check row counts, recent transactions, and application migrations.
• Run representative read and write paths against the restored copy.
• Measure the full time through application reconnection.
• Delete the temporary restore and its exposed credentials afterward.

After a restore, inspect locks, dead tuples, and query behavior before declaring the system healthy. The PostgreSQL monitoring guide covers the built-in views and external tools used for that check.