David Steele just posted a notice of obsolescence on pgbackrest.org. After thirteen years of building what became the default PostgreSQL backup tool, he's stepping away. The reason isn't burnout or a better offer. It's economics. Since Crunchy Data was sold, Steele hasn't found a role or sponsorship that would let him maintain pgBackRest full-time. So instead of doing the work poorly, he chose a hard stop.
If you run PostgreSQL in production, this should grab your attention. Choosing the right PostgreSQL backup tool is one of those decisions that feels boring until you need a restore at 3 AM. For a lot of teams, pgBackRest was the answer they never questioned. That just changed.
I've managed PostgreSQL clusters handling hundreds of millions of rows, and I've had to execute point-in-time recoveries under real pressure. The tool you pick for backups is not a checkbox exercise. It's the difference between a 20-minute recovery and losing a weekend (or worse). Here's what the three tools that actually matter do best, and which one deserves your attention right now.
What Happened to pgBackRest?
According to the notice on the official pgBackRest website, Steele made the decision to stop maintaining the project after losing corporate sponsorship. The key quote from his announcement: "Rather than do the work poorly and/or sporadically, I think it makes more sense to have a hard stop."
pgBackRest v2.58.0 is listed as the current stable release. Steele expects the project will eventually be forked, but he's clear that any fork will need to build trust independently.
This is a gut punch for the PostgreSQL ecosystem. pgBackRest wasn't just popular — it was the recommendation on virtually every "how to back up Postgres" guide written in the last five years. It's what I've defaulted to on every project since 2019. But the software doesn't vanish overnight. Your existing pgBackRest installations still work. The question is what happens six months from now when a PostgreSQL 18 compatibility issue crops up and there's nobody to write the patch.
If you've read my piece on why rewriting software from scratch is almost always wrong, you know I believe in extending the life of proven tools. But "extending" requires a maintainer. Without one, the clock is ticking.
The 3 PostgreSQL Backup Tools That Matter
Let's cut through the noise. There are really only three open-source tools worth evaluating for production PostgreSQL backups: pgBackRest (while it lasts), Barman, and pg_probackup. Each takes a fundamentally different approach.
pgBackRest is written in C, optimized for raw performance. Its killer features are parallel backup and restore operations, native support for multiple repositories, and block-level incremental backups. For large databases (multi-terabyte), pgBackRest's parallel compression alone can cut backup windows by 50% or more compared to serial approaches. It supports S3, Azure Blob, and GCS for remote storage. If you're already running it, you're not in crisis today. But you need a migration plan.
Barman is built by EnterpriseDB (EDB) and written in Python. Version 3.18.0 shipped in March 2026, and it's actively maintained with corporate backing. Barman's philosophy centers on remote management — you can control backups for multiple PostgreSQL servers from a single location. The barman-cloud-backup utility lets you push backups directly to S3 or Azure without a dedicated backup server. The Python codebase means your team can actually read and extend the pre/post backup hooks without spelunking through C internals. That matters more than people give it credit for.
pg_probackup is developed by Postgres Pro and has the most technically ambitious feature set of the three. The standout: synthetic full backups. It can construct a new full backup by merging a previous full with its subsequent incrementals, entirely without hitting the database server. It also supports block-level incremental backups natively and has advanced backup validation that goes beyond simple checksums.
All three tools fully support Point-in-Time Recovery (PITR), which you absolutely need for production. If your current backup strategy relies on pg_dump alone, you're exposed. As the Percona backup tools overview makes clear, logical dumps don't capture WAL segments and can't give you PITR.
PostgreSQL Backup Tools Compared: Feature Matrix
Here's the practical comparison that matters for production decisions:
| Feature | pgBackRest | Barman | pg_probackup |
|---|---|---|---|
| Active Maintenance | No (obsolescence announced) | Yes (EDB-backed) | Yes (Postgres Pro) |
| Language | C | Python | C |
| Parallel Backup/Restore | Yes | Limited | Yes |
| Block-Level Incremental | Yes | No (file-level) | Yes |
| Synthetic Full Backups | No | No | Yes |
| Cloud Storage (S3/Azure/GCS) | Yes (all three) | Yes (S3, Azure) | Community plugins |
| Multi-Server Management | Via multiple stanzas | Native (designed for it) | Yes |
| PITR Support | Yes | Yes | Yes |
| Encryption | Yes (native) | Yes (GPG) | No (rely on storage) |
| Backup Validation | Checksum | Checksum + WAL checks | Advanced (page-level) |
Look at that maintenance row. That's the whole story in one cell. pgBackRest is technically superior for raw performance and parallelism, but you're betting on an unmaintained codebase. Barman is the pragmatic choice if you want enterprise support and multi-server management. pg_probackup is the pick if you want the most advanced incremental strategy and you're comfortable with a smaller community.
Which Tool Should You Pick Right Now?
Here's my honest take, based on having run all three in various environments.
If you're starting fresh, go with Barman. It has the strongest corporate backing (EDB is the largest dedicated PostgreSQL company), the most active development, and the smoothest cloud integration story. The Python codebase means your DevOps team can actually read and extend the hooks without learning C internals. Yes, it's slower than pgBackRest for parallel operations on massive datasets. But for databases under 2TB — which is most of them — you won't notice.
If you're running pgBackRest today, don't panic-migrate. Your backups still work. But start evaluating Barman or pg_probackup this quarter. The risk isn't that pgBackRest breaks tomorrow. The risk is that PostgreSQL 18 ships a change that requires a backup tool update, and nobody's home to write it. I've seen this exact scenario play out with other orphaned tools. Everything's fine until it isn't, and then you're doing emergency migrations under pressure. That's how you lose data.
If you have multi-terabyte databases and backup windows are genuinely tight, look hard at pg_probackup. Synthetic full backups are a real differentiator. Instead of running a full backup every Sunday that hammers your replica for hours, you let pg_probackup synthesize one from incrementals. Having managed PostgreSQL performance at the kernel level, I can tell you that reducing I/O pressure during backup windows is not a minor optimization. It directly impacts query latency for your users.
The best backup tool is the one your team actually tests restores with. A perfectly configured pgBackRest that nobody's validated in six months is worse than a basic Barman setup with weekly restore drills.
What About WAL-G?
I should mention WAL-G, the successor to WAL-E originally developed at Citus (now Microsoft). It's written in Go, it's lightweight, and it's built for cloud-native environments. If your PostgreSQL runs on Kubernetes and you're pushing everything to S3, WAL-G deserves a look. But it's narrower than the big three. Think of it as a sharp knife rather than a Swiss Army knife. It handles WAL archiving and base backups well but lacks the management features of Barman or the synthetic backup capabilities of pg_probackup.
For teams already weighing cloud infrastructure decisions, WAL-G's simplicity is appealing. But for most production setups, Barman or pg_probackup will serve you better long-term.
The Bigger Problem Nobody's Talking About
Steele's departure from pgBackRest isn't just a tooling story. It's an open-source sustainability story. Here's someone who built one of the most critical pieces of PostgreSQL infrastructure — used by thousands of companies, many of them Fortune 500 — and he couldn't find sponsorship to keep working on it.
This pattern keeps repeating. A single maintainer builds something essential. Companies build their entire data strategy on top of it. Funding dries up and everyone acts surprised. I've shipped enough features on top of open-source infrastructure to know this cycle by heart.
If your company relies on pgBackRest, Barman, or any open-source database tool, fund the maintainers. Contribute upstream. Hire someone to work on it part-time. The cost of sponsoring an open-source maintainer is a rounding error compared to the cost of a failed database restore.
My prediction: within 12 months, someone will fork pgBackRest. It might be a cloud provider, it might be a consultancy, it might be a community effort. But it won't be the same project, and it won't have the same level of trust on day one. If you're making infrastructure decisions today, bet on the tools with proven, funded maintenance behind them. Barman has EDB. pg_probackup has Postgres Pro. That's not exciting, but it's the boring answer. And this is one of those things where the boring answer is actually the right one.
Originally published on kunalganglani.com
Top comments (0)