For about three weeks this spring, the most popular PostgreSQL backup tool in the world looked dead. On April 27, 2026, David Steele — pgBackRest’s creator and effectively its sole maintainer — posted that he was stopping work on it. Crunchy Data had funded his time for years, the acquisition ended that, and he couldn’t find replacement sponsorship or a job that left room to keep going. The last release, v2.58.0, had shipped in January. That was going to be it.
If you run self-managed Postgres, you probably remember the group chat that day. People who hadn’t thought about their backup tooling in years suddenly wanted to know what else was out there.
Then it un-died. On May 18, Steele announced that pgBackRest will continue, funded by a coalition of six sponsors — AWS, Supabase, pgEdge, Tiger Data (the TimescaleDB folks), Percona, and Eon.io — with a plan to bring on a second maintainer. The whole point of the coalition structure is that no single acquisition can ever pull the rug again.
So the headline answer is: pgBackRest is fine. Keep using it if you already do. But the scare exposed something worth sitting with, and it’s a good excuse to actually compare the four tools that matter, because most teams pick one by inertia and never look again.
The thing the scare actually taught us
pgBackRest was a single-maintainer project carrying an enormous amount of production Postgres. That’s not a knock on the code — it’s excellent, and the block-level incremental engine is genuinely the best in the field. It’s a knock on the bus factor. One person’s funding situation changed and a huge chunk of the database world spent three weeks reading “if not pgBackRest, then what” blog posts.
Every tool here has some version of this risk, and it’s the lens I’d actually use to choose in 2026:
- pgBackRest — was single-maintainer, now coalition-funded. Risk just got better than it’s ever been.
- WAL-G — community project, broad contributor base, no single corporate owner. Diffuse but alive.
- Barman — backed by EDB (EnterpriseDB), a real company with a commercial Postgres business.
- pg_probackup — built by Postgres Professional, a Russian Postgres vendor. Actively developed, but the geographic and sanctions picture is a real consideration for some shops.
None of these is a wrong answer. But “who keeps the lights on, and what happens if they stop” is a question you should be able to answer for whatever you depend on. Most people couldn’t on April 27.
Backup basics, fast
Skip this if you live in this world already.
Postgres backups come in two flavors. Logical backups (pg_dump) export your data as SQL or a custom archive — portable, great for moving a single database, painful and slow for anything large. Physical backups copy the actual data files on disk. All four tools here are physical-backup managers, because that’s what you want once your database is bigger than a few gigabytes.
The magic ingredient is WAL archiving. Postgres writes every change to a write-ahead log before it touches the data files. If you take a physical base backup and then continuously archive the WAL, you can restore the base backup and replay WAL up to any moment in between — that’s Point-in-Time Recovery (PITR). Dropped a table at 14:32? Restore to 14:31. This is the entire reason these tools exist instead of a cron job running tar.
The differences between the four come down to how cleverly they do incremental backups (only copying what changed), how well they talk to object storage like S3, how fast they restore, and — back to the theme — who maintains them.
pgBackRest: still the one to beat
pgBackRest does block-level incremental backups. Instead of “this file changed, re-copy the whole file,” it tracks changes at the page level inside files, so a backup of a mostly-idle 2 TB database moves megabytes, not gigabytes. It runs backups and restores in parallel across multiple cores, compresses well (lz4, zstd, gzip, bzip2), and v2.58.0 sharpened its object-storage support with HTTP for S3, GCS, and Azure plus dynamic upload chunk sizing.
Restores are where it really pulls ahead. Parallel restore with delta mode means it only fetches the blocks that differ from what’s already on disk, which matters enormously when you’re rebuilding a replica or doing disaster recovery against a multi-terabyte cluster and every minute of downtime costs money.
The config is declarative and sane once you learn it. It handles full, differential, and incremental backups, multi-repository setups (back up to local disk and S3 at once), encryption at rest, and retention policies that mostly do what you’d expect.
What’s not to love? The learning curve is real — the mental model of stanzas, repositories, and the archive command takes an afternoon to click. And until three weeks ago, the maintenance picture was a liability. Now it’s arguably the safest of the four. If I were starting a self-managed Postgres deployment today and didn’t have a strong reason otherwise, this is still my default.
WAL-G: the cloud-native pick
WAL-G is written in Go, ships as a single static binary, and was built from the start to push everything to object storage. If your Postgres lives on Kubernetes or a cloud VM and your backups go straight to S3, GCS, Azure Blob, or an S3-compatible store like Backblaze B2 or Wasabi, WAL-G feels like it was designed for exactly your setup. Because it probably was.
It does delta backups — page-level deltas against a previous backup — so it’s competitive with pgBackRest on the “don’t re-upload the whole database” axis, though its incremental engine isn’t quite as refined. It’s lightweight, fast, and the single-binary distribution makes it dead simple to drop into a container image. It also handles MySQL and a couple of other databases, if you’re running a mixed fleet.
The trade-offs: documentation is thinner, the config is more “read the flags and figure it out” than pgBackRest’s guided model, and the project is community-run without a single corporate backer driving a roadmap. That’s a strength for resilience and a weakness if you want someone to call. For cloud-resident Postgres where S3 is your source of truth, though, I’d reach for WAL-G before anything else.
Barman: the on-prem fleet manager
Barman, from EDB, comes at the problem from the opposite direction. It’s designed to sit on a dedicated backup server and manage backups for many Postgres instances from one place. If you’re running a fleet of on-prem or VM-based databases and you want a central console with a clear barman list-backup view across all of them, this is the tool that thinks the way you do.
It does incremental backups via rsync — copying changed files between runs, plus a block-level mode layered on top — which is functional and battle-tested but not in the same league as pgBackRest’s manifest-driven page tracking. Where Barman shines is operational ergonomics for multi-server estates: streaming WAL via pg_receivewal, replication-slot management so you never lose WAL, and the fact that there’s a commercial vendor behind it if you need enterprise support contracts.
It’s less of a natural fit for a pure cloud-native, push-to-S3 world — it can do object storage, but its heart is in the centralized-backup-server model. For an enterprise running its own Postgres on its own iron, with compliance people who want one auditable place to see every backup, Barman is the pragmatic choice.
pg_probackup: the clever one with an asterisk
pg_probackup, from Postgres Professional, has the most interesting incremental story of the bunch. It does page-level incremental backups, and crucially it supports synthetic full backups — it can merge a previous full backup with its incrementals to produce a new full backup without reading from the production server at all. That takes backup I/O pressure off your live database, which is a genuinely nice trick at scale. Recent versions claim restore-from-incremental-chain speedups of up to an order of magnitude, plus multi-timeline incremental chains.
It’s actively maintained — the community edition is up to the 2.5.x line with ongoing PostgreSQL 16+ support — and the technical work is legitimately strong.
The asterisk is twofold. The community is smaller than WAL-G’s or pgBackRest’s, so you’re leaning on a narrower base of contributors and Stack Overflow answers. And it’s developed by a Russian vendor, which for a lot of organizations raises sanctions, supply-chain, and procurement questions that have nothing to do with the code quality. Whether that matters is entirely about your company’s risk posture, but it’s a real factor and pretending otherwise would be silly. If those concerns don’t apply to you and you want the most sophisticated incremental engine with the lowest production overhead, it’s worth a serious look.
Quick comparison
| pgBackRest | WAL-G | Barman | pg_probackup | |
|---|---|---|---|---|
| Incremental | Block-level (best) | Page deltas | rsync + block | Page-level + synthetic full |
| Language | C | Go | Python | C |
| Object storage | S3/GCS/Azure | S3/GCS/Azure/B2 | S3 + dedicated server | S3/cloud |
| Best for | Default self-managed | Cloud-native / K8s | On-prem fleets | Low-overhead incremental |
| Maintenance | Coalition (6 sponsors) | Community | EDB | Postgres Professional |
| Learning curve | Moderate | Low–moderate | Moderate | Moderate–high |
Numbers like restore speed are workload-dependent enough that I’d distrust any single benchmark you read, including one I’d run. Test against your own data shapes before you commit.
Does any of this apply to RDS or Aurora?
Mostly no, and that’s worth saying plainly. If you run Amazon RDS, Aurora, Cloud SQL, or any managed Postgres, the provider handles physical backups and PITR for you — you don’t install pgBackRest on RDS, you can’t, and you shouldn’t try. The pgBackRest drama was irrelevant to managed-Postgres users except as gossip.
These tools matter when you own the instance: bare metal, VMs, Kubernetes with an operator, or a managed service that explicitly hands you backup control (some operators like CloudNativePG actually use Barman or WAL-G under the hood). The further you move toward fully managed, the more this whole question becomes someone else’s job — which is, increasingly, why teams pay for managed Postgres in the first place.
So which one
If you already run pgBackRest, do nothing. It’s healthier now than it was in March. The migration most people half-started in late April was a solution to a problem that no longer exists.
Starting fresh and cloud-resident with everything in S3 and Postgres on Kubernetes? WAL-G. Running a fleet of on-prem databases that you want to see from one backup server, with a vendor to call? Barman. Want the cleverest incremental engine and the Postgres Professional origin isn’t a blocker for your org? pg_probackup. Want the safest, most-supported default that does everything well? pgBackRest, again.
The one thing I’d actually do this week, regardless of tool: run a real restore. Not “the backup job exited 0” — an actual restore into a throwaway instance, with PITR to a specific timestamp, timed end to end. The April scare made everyone audit which tool they use. Far fewer people checked whether their restores work. A backup you’ve never restored from is a hope, not a backup.