pgBackRest has long been considered one of the most trusted backup tools in the PostgreSQL space. It’s also, as of 2026, no longer maintained. Those two facts sitting next to each other should give every DBA and backend engineer a moment of pause.
I’ve been reviewing database tooling for a while now, and this one stings a little differently. Not because the maintainer made a bad call — they didn’t — but because so many teams built their entire backup strategy around this tool and are now quietly scrambling to figure out what comes next.
What Actually Happened
The maintainer posted a clear, honest note on the pgBackRest GitHub page. No drama, no finger-pointing. The message was direct: pgBackRest is no longer being maintained. If you want to fork it, go ahead — but pick a new name. That last part is actually a thoughtful move. It signals that the original project is done, and any continuation should be treated as a separate thing with its own identity and ownership.
The PostgreSQL community on Reddit and Hacker News picked it up fast. The reactions ranged from genuine sadness to mild panic, which tracks. One user on Reddit noted they had just finished writing a detailed guide for reliable PostgreSQL backups using pgBackRest. That kind of timing is brutal, and it’s a good reminder that open source dependencies carry real operational risk.
Why This Matters More Than a Typical Deprecation
Most tools fade out slowly. They stop getting updates, issues pile up unanswered, and eventually someone writes a migration guide. pgBackRest got a clean ending, which is actually rarer and more respectful than the slow ghost-town treatment. But the impact on teams using it in production is the same either way.
pgBackRest wasn’t a niche utility. It was a go-to recommendation for teams that needed parallel backup, WAL archiving, incremental backups, and point-in-time recovery — all in one place. It handled large databases well. It had solid documentation. For a lot of shops, it was simply the answer when someone asked “how do we back up Postgres?”
That answer now needs to change.
What You Should Actually Do Right Now
If you’re running pgBackRest in production, here’s my honest take as someone who reviews this stuff for a living:
- Don’t panic, but don’t wait either. An unmaintained tool won’t break overnight, but security patches and compatibility updates with newer Postgres versions will stop coming. That clock is ticking.
- Start evaluating alternatives now, not when something breaks. The worst time to research backup tooling is during an incident.
- Watch the fork space. The maintainer explicitly invited forks with new names. Someone in the community may pick this up and carry it forward. Keep an eye on what surfaces over the next few months.
- Document your current setup thoroughly before you migrate. Whatever you move to, you’ll want a clear picture of your existing backup schedules, retention policies, and restore procedures.
The Alternatives Worth Looking At
I’m not going to pretend there’s a perfect drop-in replacement, because there isn’t. But the PostgreSQL backup space has other solid options worth evaluating depending on your setup.
Barman (Backup and Recovery Manager) from EnterpriseDB is probably the most direct comparison. It’s actively maintained, well-documented, and handles WAL archiving and point-in-time recovery. If you were using pgBackRest in a fairly standard way, Barman is likely your first stop.
WAL-G is another strong contender, especially if you’re running in cloud environments. It’s built for speed and cloud storage integration, and it’s been gaining traction for a reason. Lighter weight than pgBackRest, but capable for most use cases.
For teams already deep in a managed cloud setup, leaning on native backup features from your cloud provider might actually be the pragmatic call. Not always the most flexible option, but it removes the maintenance burden entirely.
A Note on Open Source Sustainability
This situation is a good prompt to think about how your team treats open source dependencies. pgBackRest was maintained by a small number of people — possibly one primary maintainer — and that’s true of a lot of critical infrastructure tooling. When those people move on, the project moves on too.
If a tool is load-bearing in your stack, it’s worth asking: who maintains this, and what happens if they stop? That’s not a criticism of open source — it’s just honest operational thinking.
pgBackRest had a good run. The maintainer handled the ending with class. Now the job falls to the community, and to each team, to figure out what comes next.
🕒 Published: