PostgreSQL backup tools compared

Written by SafeGrd's founder, so SafeGrd is on this list. Each entry starts with what that tool does better than the others, including better than SafeGrd. Facts come from each project's own documentation and pricing page, read in October 2026. If a page has changed since, the project's page is right.

The short version

A physical backup copies the database's files and its write-ahead log, so it restores to any second you choose, onto the same major version. A logical backup is a pg_dump: it restores onto a newer version or another provider, one table at a time if you want, and only to the moment it was taken. pg_dump, pg_basebackup or pgBackRest goes through the difference in full.

pg_dump and cron

Best at: nothing to install and nothing to pay. pg_dump ships with PostgreSQL, and a five-line script with set -o pipefail, age and aws s3 cp gives an encrypted copy in a bucket every night.

What it leaves to you: nothing tells you when cron stopped running or the dump came out short, and nothing restores it until the day you need it. How to back up PostgreSQL to S3 is the script, with the checks that make it fail loudly.

pgBackRest

Best at: large databases that need point-in-time recovery. Full, differential and incremental backups, parallel compression, and repositories on S3, Azure, GCS or SFTP. It restores a multi-terabyte cluster faster than any logical tool can, because it copies files instead of replaying SQL.

What it leaves to you: encryption is off until you configure it, the repository is deletable by the credentials that write it unless you add a lock, and pgbackrest verify checks checksums, not that the data restores. Many teams run it for recovery and something else to test. (SafeGrd and pgBackRest)

Barman

Best at: one backup server for many PostgreSQL servers. Barman, maintained by EDB, pulls base backups and streams WAL from each database to a central host, with point-in-time recovery and retention policies per server. Its barman-cloud commands write straight to S3, Azure or GCS from the database host, which is what the CloudNativePG operator uses on Kubernetes.

What it leaves to you: the backup server itself, and testing that a restore works.

WAL-G

Best at: physical backups straight to object storage with little setup. Delta backups, several compression choices, and encryption built in. The same tool backs up MySQL and MongoDB, and Zalando's Postgres Operator uses it on Kubernetes.

What it leaves to you: scheduling, alerting and restore testing.

Databasus

Best at: free scheduled restore tests on your own server. It backs up PostgreSQL, MySQL, MariaDB and MongoDB, streams WAL for point-in-time recovery, and restores the newest backup into a throwaway container to check it, all under Apache 2.0 with a web interface.

What it leaves to you: running and updating the server it lives on, and keeping its storage out of reach of the credentials that reach production. (SafeGrd and Databasus)

SimpleBackups

Best at: breadth. Databases, servers, storage buckets and SaaS apps from one hosted console, with schedules down to minutes on the higher plans.

What it leaves to you: restore testing, which it reminds you to do. Plans count backup jobs, 5 on the $49 plan. (SafeGrd and SimpleBackups)

BackupDrill

Best at: Supabase with no setup. It connects to a Supabase project by sign-in, backs up the database and the Storage files, and restores the backup in its own cloud every week on paid plans.

What it leaves to you: anything that is not Supabase, and a lock on the bucket. (SafeGrd and BackupDrill)

AWS Backup

Best at: RDS and Aurora inside AWS. Point-in-time recovery, Vault Lock so nobody in the account can delete a backup, scheduled restore testing, and Audit Manager reports, with nothing to run.

What it leaves to you: checking the data inside a test restore (a Lambda function you write), and anything outside AWS. A restore lands in AWS only. (SafeGrd and AWS Backup)

SafeGrd

Best at: proof that a backup restores, which someone outside the team can check. Every backup is encrypted on your host and written under Object Lock to your bucket or SafeGrd's. On a schedule, a drill restores the newest one into a throwaway database, counts every table's rows against what was backed up, and signs the result into a chained record an auditor can verify offline. It covers PostgreSQL, MySQL, MongoDB, SQLite, files and mailboxes from one install, and databases with no host of their own run on a machine SafeGrd starts for each job.

What it leaves to the others: point-in-time recovery. SafeGrd backs up as often as hourly, so a team that needs to restore to the second runs pgBackRest, WAL-G or its provider's PITR beside it, and SafeGrd for the tested copy kept elsewhere.

Run your first Fire Drill See pricing

How to choose

• Over a few hundred GB, or you need to restore to the second: a physical tool (pgBackRest, Barman or WAL-G), or your provider's point-in-time recovery.
• On Supabase, Neon, Railway or another platform with no server: a tool that runs elsewhere: BackupDrill for Supabase alone, SafeGrd from a GitHub Actions workflow or on its own machines, SimpleBackups.
• Everything in AWS: AWS Backup, plus a copy outside the account.
• Someone else will ask whether your backups restore (a customer, an auditor, an insurer): something that tests on a schedule and keeps the result: Databasus on your own server, or SafeGrd with a signed record.

Whatever you pick, restore a backup once by hand before you rely on it. How to test that a backup restores has the steps.

Sources

• pgBackRest: User guide
• Barman documentation
• WAL-G on GitHub
• Databasus on GitHub
• SimpleBackups: Pricing
• BackupDrill: Pricing
• AWS Backup: Restore testing