pgBackRest Got Archived, Then Rescued: The Bus-Factor Checklist Every Self-Hosted Postgres Backup Stack Needs

On April 27, 2026, David Steele archived the pgBackRest GitHub repository and posted a document titled, without much ceremony, "Notice of Obsolescence." Thirteen years as the tool's sole maintainer ended with one line: "Rather than do the work poorly and/or sporadically, I think it makes more sense to have a hard stop." Every production Postgres fleet using pgBackRest for physical backups and WAL archiving woke up to a backup tool that would never ship another patch — including security patches — again.

Three weeks later it wasn't dead. By May 18–19, a coalition of nine companies had agreed to fund its continuation, and pgBackRest 2.59.0 shipped on July 20 as the first release under the new arrangement. The tool survived. But "it survived" isn't the useful takeaway here — the useful takeaway is the five questions this episode exposes that most teams have never asked about the backup tooling sitting underneath their "your data is safe, we run backups" promise. Those five questions, and a worked example applying them to the two real backup paths a CloudNativePG operator can actually choose today, are below.

The timeline: what actually happened, in order​

The root cause wasn't "the maintainer got tired," even though burnout is part of the story. It was concentration: pgBackRest's primary corporate sponsor for years was Crunchy Data, and when Crunchy Data was sold, no successor funding model existed to replace it. One acquisition, on the other side of the world from any pgBackRest user's own infrastructure decisions, put a maintenance halt on a tool sitting inside thousands of production Postgres backup runbooks.

The checklist: five questions for every tool in your actual backup path​

The pgBackRest story is not really about pgBackRest. It's a concrete instance of a generic risk: a single-vendor-sponsored dependency with no succession plan sitting underneath an availability promise you've made to someone else, whether that someone is a customer, your own team, or a config file that assumes the tool will always be there. Before trusting any tool in a backup or recovery path — not just Postgres, not just this one project — run it through five questions:

1. How concentrated is the funding? One corporate sponsor, or several? A single point of failure in funding is a single point of failure in maintenance, even if the code itself is fine.
2. Is there a governance entity independent of any one funder? A foundation or neutral steering body (CNCF, Apache, a nonprofit) can outlive any single sponsor's decision to walk away. A GitHub org owned by one person or one company can't.
3. Is there more than one person who can actually ship a release? Funding pays for maintainers' time; it doesn't create maintainers. A tool with nine sponsors and one person who understands the codebase has diversified the money, not the bus factor.
4. Does your restore path survive the tool freezing exactly as it is today? If the project stopped shipping patches tomorrow, could you still restore from your existing backups with the version you're already running? (pgBackRest's answer during the archive window was yes — existing backups stayed restorable, only future development stopped. Not every tool's does.)
5. Is there a credible fork or alternative you could pivot to inside your own recovery time window? Not "does one exist somewhere," but "have you actually confirmed you could cut over to it before your next incident, not during one."

Applying it: the two real choices a CloudNativePG operator has today​

This isn't a hypothetical exercise — CloudNativePG operators have exactly two supported backup paths right now, and the checklist gives different answers for each.

Barman Cloud Plugin (CNPG's default). CloudNativePG itself joined the CNCF Sandbox in January 2025 and is explicitly governed as a vendor-neutral, community-owned project, not a single company's product — a direct answer to question 2. The Barman Cloud Plugin that ships as CNPG's default backup path was originally built by EDB and now develops under that same CNCF-adjacent, multi-maintainer governance, not one engineer's personal repo. Question 3's answer is a maintained team, not a single point of failure. A CNPG fleet using the default Barman Cloud Plugin path was never touched by the pgBackRest archival at all — not because the drama didn't matter, but because the checklist already favored this path before the drama happened.

The Dalibo pgBackRest CNPG-I plugin. This is the more interesting case, because it's new and it exists specifically because pgBackRest just proved it has real demand — Dalibo shipped it three weeks after the rescue was confirmed, not before, which is itself informative: the ecosystem's answer to "is pgBackRest still worth building on" was yes, quickly. But run it through the checklist honestly: it's a single-vendor plugin (Dalibo) wrapping a tool whose upstream is still funded by a coalition rather than governed by a foundation, and the plugin itself shipped as an explicitly experimental v0.0.3. That's not a reason to avoid it — pgBackRest's parallel compression, block-level incremental backups, and delta restore are real capabilities Barman doesn't match feature-for-feature — but it's a different risk profile than the default path, and a fleet that adopts it should know that going in, not discover it the next time a sponsor gets acquired.

Neither answer is "use the other one." The point of running the checklist is that it gives you a documented reason for the choice you made, instead of a runbook that silently assumed a tool would always be there because it always had been.

Is the fix durable, or did the risk just move?​

Worth asking honestly: is a nine-company funding coalition actually a different kind of protection than a single corporate sponsor, or does it just diversify the money while leaving the same single point of failure — one person able to ship a release — fully intact? Steele's own framing ("no longer reliant on a single sponsor") is correct as far as it goes: nine companies each deciding independently to pull funding simultaneously is a much less likely event than one company being acquired. But question 3 above still applies with full force. The funding got fixed. The bus factor — how many people can actually cut a release if Steele is unavailable — is a separate question this rescue doesn't automatically answer, and it's exactly the kind of thing worth checking in the project's own governance docs before betting a fleet's recovery story on it, rather than assuming a funding announcement settled it.

What this means for a self-hosted platform's own stack​

A self-hosted PaaS running CloudNativePG for tenant Postgres doesn't get to skip this audit just because it owns the hardware. bex doesn't manage databases for tenants — that's a deliberate non-goal, not a gap — which means the Postgres cluster sitting next to a deployed app is the operator's own CNPG install, running whichever backup path they configured. Owning the infrastructure removes the "wait for a vendor's incident update" problem entirely: there's no support ticket queue between you and your own backups. It doesn't remove the responsibility to have actually run the five questions above against every tool in that path before you needed them, not after.

bex is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. It won't pick your Postgres backup tool for you, but it'll run next to whichever one passes your own checklist. Star the repo on GitHub or deploy your first app today.

Sources​

• Notice of Obsolescence — The Build.
• pgBackRest is no longer maintained — LWN.net.
• pgBackRest is archived, what now? — Percona Community.
• Backrest's back, alright! — Percona Community.
• pgBackRest will continue — Noise.
• pgBackRest plugin for CloudNativePG — Dalibo Blog.
• dalibo/cnpg-plugin-pgbackrest — GitHub.
• Barman Cloud CNPG-I plugin — GitHub.
• PostgreSQL Operator CloudNativePG Hits the CNCF Sandbox — The New Stack.