After pgBackRest's Close Call, Postgres Shops Are Drafting New Runbooks For Continuity

For about a week in late April, the most widely deployed backup tool in production Postgres was officially unmaintained. The rescue arrived inside seven days. A coalition formed, a continuity fork shipped, and pgBackRest survived. The Read Replica covered that rescue last week, but in the weeks since, some senior practitioners stopped reading the rescue as a one-off near-miss with a good outcome, and started running audits on the rest of their stack. The stack reviews look different depending on where the operator sits, but the broader structural question persists as to whether the Postgres ecosystem can fund stewardship at the rate it consumes it.

Approaching the audit

Svyatoslav Pavlov, a DevOps engineer who writes pgBackRest into production at a high-load blockchain fintech, treated the announcement as a procedure trigger rather than a software problem.

"My first impression was honest disbelief, then resignation," he said. "pgBackRest is the standard backup stack for Postgres at any scale when pg_dump stops being viable. Watching the maintainer post that he couldn't find a sponsor after corporate backing ended is a specific gut-punch for me. Thousands of orgs depend on this, none paid enough to keep it alive." The binary still works and recovery still works. What changed, he said, is the maintenance horizon. Six months out, there is no guaranteed CVE patch timeline. "That's the moment something stops being a stable dependency and starts being legacy code you happen to be running."

Pavlov said he follows a more linear order of operations these days: pin the binary version, mirror the repo with releases included, verify a full backup-to-restore on a clean system without any pgBackRest-team infrastructure dependencies, and rewrite the disaster recovery runbook so it references a specific SHA rather than latest.

Traditional disaster recovery runbooks plan for hardware failure, data corruption, and region outages, but the tool itself becoming an orphan is a different failure mode. The runbook change is the one most teams skip, but also the one that determines whether a recovery procedure works in eighteen months into the future, when the upstream fork landscape has reshuffled and the binary you wrote into your tooling no longer exists at that URL. Percona, which includes pgBackRest in its Distribution for PostgreSQL and ships an opinion on backup tools to a sizable enterprise customer base, has effectively given the same advice, essentially saying, "keep using it while the community works the longer question."

The deeper change Pavlov flagged is what the episode did to his evaluation framework for everything else. Commit cadence and GitHub activity used to be a viability signal, but as Pavlov frames it now, that signal breaks down the moment one person can keep a project looking healthy for years before disappearing in a quarter. The question he now asks before adopting anything new is no longer "is this maintained" but "what's the off-ramp if this stops tomorrow."

What a healthy GitHub actually hides

The audit reframe lands harder if you have seen it from inside. Andrew Borodin, a PostgreSQL contributor and a longtime maintainer of WAL-G, runs his project differently from the single-maintainer-with-sponsor model pgBackRest had. WAL-G carries roughly ten or twelve companies contributing committers, and Borodin is the one who appoints new ones. It is also the backup tool most people named when asked which stack absorbs pgBackRest's traffic if pgBackRest does not come back.

Borodin has a hard-earned answer to why GitHub activity is a bad signal. WAL-G's remote backup support was contributed years ago by a maintainer who left the project when his employer changed. The Postgres server protocol then shifted under the feature, and for two years across multiple releases the remote-backup path was broken with no one to fix it. The issue stayed open until Borodin found another hacker willing to pick it up.

WAL-G is the obvious adjacent example, even with the broader governance shape. pgvector is everywhere thanks to AI, and the maintenance is single-vendor. pg_partman, pg_repack, pg_cron are each critical for specific deployment patterns and each carries one or two maintainers. Outside Postgres entirely, rsync is behind petabytes of data movement and has a famously small maintainer pool. CoreDNS sits in front of every Kubernetes service. Bind. ntpd. Anything in the certificate verification path that is not OpenSSL.

"We are not short on tools"

For those who have lived through earlier versions of this audit, the response is more procedural than panicked. Emrah Becer is a senior database administrator at the European Patent Office who has spent twenty years administering Postgres and Oracle across government and defense environments. He treats the pgBackRest archive as a routine migration prompt rather than a crisis. "We love pgBackRest, and we are still using it in many environments," Becer said. "But we are not short on tools." His selection framework is environment-specific: WAL-G for cloud-native deployments storing backups in S3-compatible object storage, Barman for on-prem with traditional storage. The same migration that takes a week in one environment can take a quarter in another.

What Becer flags as more critical than tool selection is the discipline of testing recovery before it is needed. "You should not wait until something bad happens. Just test your recovery scenarios. Have your runbooks ready before you actually hit the problem." It's the same operational discipline Pavlov is now applying to dependencies he previously trusted on commit cadence alone, just made routine by twenty years of institutional repetition.

Pavlov pulled the same thread on the broader pattern. "Dollars-of-data-protected to dollars-of-funding ratio is wildly skewed. Maintainers don't make it visible, partly because they're busy and partly because it sounds like begging. The only signal you get is the announcement the work has stopped."

What funding alone doesn't fix

We also spoke with Derk van Veen, a database specialist at a payments platform built fully on open source software and administered in-house. Van Veen runs the 100TB-plus Postgres deployments behind that posture, and he has been thinking for years about the gap between OSS dependence and OSS funding.

"If you rely on something you implemented as a company, you rely on it, whether it's something small or something big. Maybe you're moving data from one place to another place, but if it stops, maybe you're no longer DORA compliant. You might lose your license."

He was referring to the EU's Digital Operational Resilience Act, fully applicable since January 2025, which requires regulated financial entities to formally manage ICT third-party risk across their critical functions. The regulation does not care that the dependency is free, but that the entity using it has accounted for its continuity. A pgBackRest archive, he said, is an ICT incident that has to be documented, assessed, and responded to.

The deployments van Veen runs put OSS dependencies on a 10-to-20-year horizon. "I implement this in a bigger company, this product might be there for the next 10, 20 years. What is the guarantee of your open source project for the next 20 years? Am I going to re-evaluate every year?"

Signals like number of contributors over the last year, release cycle, and patch frequency matter. But the problem is that those are exactly the signals Pavlov said break once one capable person can carry a project that looks healthy. The review needs another column, and van Veen's view is that the column is funding model. "There's a big gap between people developing open source, people using open source, and people able to pay for the people working on the open source stuff," he said. Hyperscalers run their own OSS teams. Below them, the tail gets longer and quieter. "There are so many companies who have like a thousand engineers. They can spend a few FTE on developing open source if they are relying on it." Most don't. "You have this community that builds something out of love almost, and you say, yeah, now we make money on top of it and we don't care about you."

Commercial features inherit continuity where non-commercial work can't

But the funding-model column is itself incomplete, and Borodin's view from the maintainer seat is what complicates it. Commercial-funded features fail too, just along a different axis. "If we are talking about features that affect someone's business, it's super easy to find someone who will fix it. If one committer leaves from a company like Supabase," he said, "they will appoint someone else. The problem only arises when you have to deal with truly non-commercial Postgres. Core Postgres doesn't belong to any single commercial entity. So no one will appoint someone to help fix our connectivity, our compatibility."

In operator terms, feature work bankrolled by a company inherits continuity by default, because the company has an interest in the feature continuing to work. The work in the gap between corporate priorities and the public good is what fails. It's the gap where pgBackRest sat for thirteen years.

From inside the maintainer seat, it's the same problem. "Writing code was always cheap, actually," Borodin said. "We don't have shortage of code. Building a community of people who maintain and who want to make the system better, that's what important." The criterion he uses when accepting features into WAL-G is built around that observation. He recently approved a contribution from Supabase engineers adding new functionality, and the backup tool Supabase has built its own continuous Postgres backup stack around is now carrying it. Technical merit was not the deciding factor. "If you add some features, there must be someone who is responsible, who will answer initiatives, who will review changes and all that stuff. They found several engineers that are in charge of these features. I gave them a commit bit, they introduced Supabase features and they are supporting it." Whether the contributor will still be around to support the feature in five years is the question that decides whether it gets merged, and it is the same question Pavlov is now asking about every dependency in his stack and van Veen is asking about every line in his audit.

What van Veen is proposing, semi-rhetorically, is a centralized funding body that collects from companies using OSS and redistributes to maintainers. "If every company using Postgres gives a little bit back," he said, "a little bit of money to a developer working on Postgres, or any open source product, that would be so much more sustainable." Percona's product team argued for a version of the same idea in its postmortem, framing the long-term options as either a foundation-backed structure, a coordinated multi-vendor stewardship model, or pulling critical tooling into Postgres core. None of those models exists for pgBackRest yet, and none of them will exist by default for the next dependency in line.

The second-order concern van Veen surfaced was about new projects as opposed to existing ones. "If you have enough tokens to burn, you can take any open source project, rebuild it in a different language and make a company on top of it. Why would people open source something today?" That is a contested claim. It is also one the Postgres community will have to take seriously, because the model of new infrastructure tooling starting as a hobby project and getting adopted into production stacks before its funding is settled is visibly broken.

Why the next crisis won't be as clean

The audit-everything-else exercise is more urgent than it looks because the foundation underneath it is itself incomplete. The Postgres core project's built-in backup primitives are less complete than the community sometimes treats them. The interface for archiving WAL, the substrate for point-in-time recovery, is sequential, has no built-in encryption, no compression, and was designed before clouds became popular. Production teams have been compensating for this through tooling like pgBackRest and WAL-G for more than a decade. "Point-in-time recovery actually is the weakest part in a core that has to be developed," Borodin said. "I'm currently working mostly on fixing bugs in point-in-time recovery."

Becer makes the same point from the operator side. The default backup tool that ships with core Postgres, pg_basebackup, handles small environments adequately but breaks at enterprise scale. "If your database is very large or you have a very busy environment, that default tool will not be adequate. That is why Barman, pgBackRest, or WAL-G were developed in the first place." The convergence Borodin and other backup-tool maintainers have been describing for years, folding the satellite tools' best ideas back into core, would close this gap. That is the same vision Percona's postmortem named as one of the long-term options, and the one pgBackRest's own maintenance update referenced. It is not a near-term outcome, and until then, the satellite tooling continues to bear load, and the review Pavlov is running this week is the only governance most operators have.

The structural question, still deferred

So even though pgBackRest's near-death was the version of this story with the kindest possible ending, the structural question of whether the ecosystem funds stewardship at the rate it consumes it is not answered, only deferred.

Across the experts we spoke with, the deferral now has a price tag. The cost of operating in the deferral period is the cost of audits Pavlov is running this week, migrations Becer treats as operational hygiene, governance van Veen is asking for, and maintainers Borodin is recruiting one at a time at conferences. Compliance frameworks are increasingly making that work mandatory rather than discretionary, and pushing it into architecture rather than runbooks. Large operators are already doing it, whether or not they want to.

The views and opinions expressed are those of the individuals and do not represent the official policy or position of any organization.