pgBackRest Loses Its Maintainer — What PostgreSQL Teams Should Do Now

What happened

pgBackRest — the backup and recovery tool that quietly underpins a huge fraction of production PostgreSQL deployments — is no longer being actively maintained. The project's GitHub repository, which had been receiving steady commits for over a decade, has gone silent. The Hacker News discussion (255 points and climbing) reflects the gravity: this isn't some niche utility. pgBackRest is, by most accounts, the default choice for PostgreSQL backup in production environments, from startups to enterprises running multi-terabyte databases.

The tool was created and almost single-handedly maintained by David Steele, a longtime PostgreSQL contributor who worked at Crunchy Data. Steele rewrote the entire project from Perl to C around 2019-2020, an effort that dramatically improved performance and reliability. He handled the bulk of commits, issue triage, documentation, and release management. When one person does all of that for a decade, the project is really a solo act with an open-source license.

The specifics of why maintenance has stopped are still emerging. Whether this is a departure from Crunchy Data, a personal decision, burnout, or a corporate reprioritization, the end result is the same: the tool that thousands of PostgreSQL operators rely on for disaster recovery has no one actively steering it.

Why it matters

Let's be direct about what pgBackRest does and why it's hard to replace. It handles full, differential, and incremental physical backups with parallel processing. It supports point-in-time recovery (PITR). It encrypts and compresses backups. It pushes to S3, Azure Blob, and GCS. It verifies backup integrity. For teams running PostgreSQL at any meaningful scale, pgBackRest isn't a convenience — it's the disaster recovery plan.

The tool is also embedded in higher-level infrastructure. Crunchy Data's PGO (Postgres Operator for Kubernetes), one of the two dominant PostgreSQL Kubernetes operators, uses pgBackRest as its backup engine. If you're running Crunchy's operator — and a lot of teams are — pgBackRest isn't something you chose; it's something that was chosen for you. The ripple effects of an unmaintained pgBackRest extend well beyond teams that explicitly selected it.

This situation also highlights a pattern that the open-source ecosystem keeps re-learning the hard way. Critical infrastructure tools with thousands of production deployments can hinge on a single maintainer who may have no formal support structure, no succession plan, and no economic incentive to continue. We saw this with OpenSSL before Heartbleed forced the industry to pay attention. We saw it with `core-js`. We saw it with `left-pad` in a more absurd form. pgBackRest is the PostgreSQL community's version of the same lesson.

The PostgreSQL ecosystem has historically been better than most at maintaining core infrastructure — the database itself has a robust, well-funded contributor base. But the tooling around PostgreSQL has always been more fragmented. Backup tools, monitoring solutions, connection poolers — these tend to be maintained by individuals or small teams at specific companies, and when those individuals move on or those companies shift priorities, the tools go with them.

What this means for your stack

If you're currently running pgBackRest in production, don't panic, but do audit. The software doesn't stop working because commits stopped. Your backups are still running. Your PITR capability is intact. But you need to think about what happens when PostgreSQL 18 or 19 introduces changes that require backup tool updates. An unmaintained backup tool becomes a ticking clock — it works until the database evolves past it.

Here's the practical decision tree:

Barman (maintained by EDB/EnterpriseDB) is the closest feature-for-feature alternative. It's Python-based, supports full and incremental backups, PITR, and cloud storage. It's heavier than pgBackRest and historically slower for large databases, but it has corporate backing and an active development team. If you need a drop-in migration path with minimal feature regression, Barman is the answer.

WAL-G (originally from Citus/Microsoft, now community-maintained) is the cloud-native option. Written in Go, it's simpler than pgBackRest, focuses on object storage backends, and has a smaller feature surface. If your backups go to S3/GCS and you don't need every feature pgBackRest offered, WAL-G is leaner and actively developed.

pg_basebackup (core PostgreSQL) got a significant upgrade in PostgreSQL 17 with native incremental backup support. For simpler setups, the built-in tooling may now be sufficient. You won't get pgBackRest's parallelism, encryption, or multi-repository support, but you also won't have an external dependency to worry about.

If you're running Crunchy Data's PGO operator, watch for official guidance from Crunchy. They have the strongest incentive to either fork pgBackRest, fund a new maintainer, or migrate their operator to a different backup backend. Their response will likely determine pgBackRest's long-term fate more than any community effort.

For teams evaluating PostgreSQL backup solutions today, the calculus has changed. The safe recommendation is now Barman or WAL-G, not pgBackRest, until the maintenance situation resolves. Factor bus-factor into your infrastructure dependency decisions the same way you factor in performance benchmarks.

Looking ahead

There are really only three outcomes here. Someone (likely Crunchy Data or another PostgreSQL-focused company) steps up to maintain pgBackRest, and it continues as before with a new steward. The project gets forked — possibly multiple times — and the ecosystem fragments around competing forks with varying quality. Or pgBackRest slowly ossifies while the community migrates to Barman, WAL-G, and PostgreSQL's improving native capabilities. The PostgreSQL community has historically been pragmatic about these transitions, but this one will be felt more acutely than most. Backup tooling isn't glamorous, which is exactly why it's so hard to find someone willing to maintain it for free.