Yesterday David Steele announced that he is stepping away from pgBackRest. After thirteen years, the most widely-deployed dedicated backup tool in the PostgreSQL ecosystem is no longer maintained. The current release, v2.58.0, is the last release. Steele asks that any forks pick a new name, which is — among other things — an act of professional courtesy from a maintainer who has clearly thought about how trust gets built and how it doesn’t get inherited.
The announcement is restrained in the way these things often are. The implications are not.
What actually happened
For most of pgBackRest’s life, Steele worked on it as part of his job. The sponsor list on the project page is short: Crunchy Data and Resonate historically; Supabase currently. Crunchy Data was the long-tenured sponsor, and Crunchy Data — as Steele puts it — was sold. (The acquirer was Snowflake.) After the acquisition, Steele’s continued employment on pgBackRest-shaped work was not, evidently, a strategic priority for the new owner. He has spent the period since looking for a role that would let him keep maintaining the project, and for sponsorship that would cover the gap. Neither materialized at the level required to make it viable.
So he stopped. This is the correct decision — he says so plainly in the announcement, and he is right — because the alternative is a slow degradation into a project that exists but isn’t really maintained, and that outcome is worse for everyone, including the users.
The fragility nobody priced in
If you operate a production PostgreSQL database of any meaningful size, you have either deployed pgBackRest, considered pgBackRest, or rejected pgBackRest in favor of something else. It is — was — the feature-complete open-source PostgreSQL backup tool. Block-level incremental backups, parallel restore, page checksum validation, S3/Azure/GCS support, encryption, and a custom protocol that doesn’t require the repository host to have direct PostgreSQL access. It is one of the most operationally-mature pieces of code in the PostgreSQL ecosystem outside the core itself.
It was maintained, primarily, by one person.
This is the part that tends to get glossed over in conversations about open-source software, so let me state it plainly. A very large fraction of the FOSS infrastructure that the modern internet runs on is maintained by individuals or very small teams, working under conditions ranging from “fully employed by a sponsor whose strategic interests happen to align” to “doing this in evenings and weekends because nobody will pay them and they care anyway.” The economic structure underneath this arrangement is not robust. It depends on the continued goodwill of sponsors, the continued health of maintainers, and the continued absence of a better-paid alternative for the maintainer’s time. Any of those three can change.
When they change, the project doesn’t necessarily die loudly. Sometimes it just goes quiet — issues stop getting closed, PRs accumulate, the website’s “current release” date gets older — and one day you realize the thing you depend on hasn’t shipped a security patch in eighteen months. The pgBackRest case is unusual mostly in that Steele is being honest about it. Most projects in this position never get an obituary; they just decay.
The broader version of this: open-source software is undercapitalized as a category. The companies that benefit most from it contribute disproportionately less than their benefit. We covered the structural reason for this in the previous post on PostgreSQL’s licensing — permissive licenses are an invitation to use freely, and the invitation is widely accepted. pgBackRest is the same problem in personal form. Not a license issue; a payroll issue.
The consolidation problem
The specific shape of this failure mode deserves attention, because it is going to happen again.
The PostgreSQL commercial-vendor world has been consolidating. EDB acquired 2ndQuadrant in 2020. Snowflake acquired Crunchy Data in 2025. These are the two largest PostgreSQL-focused company acquisitions to date, and both involved companies that employed prominent contributors to community-critical projects. 2ndQuadrant was the home of Barman, BDR, and a substantial chunk of PostgreSQL’s logical replication contributors. Crunchy Data was the home of pgBackRest, Patroni-adjacent work, and a meaningful fraction of PostgreSQL’s high-availability brain trust.
When a smaller PostgreSQL-focused company gets acquired by a larger company whose primary product is not PostgreSQL, the strategic calculus around community work shifts. The acquired company’s engineers were often funded for community work because that work was the company’s product surface — being seen as serious PostgreSQL people was the marketing. After acquisition, when the larger company has its own product surface and its own marketing, the community work becomes a cost center with no obvious P&L justification. It is, in the language of corporate strategy, no longer strategic.
The community-critical project doesn’t know this is happening until it’s already happened. There is no notice period. There is no escrow. There is no obligation, contractual or otherwise, that the acquiring company continue to fund work that the acquired company funded out of strategic self-interest. The contributor finds out when their role gets reorganized, or when their next funding cycle gets quietly declined, or — in the cleanest version — when they are told directly that this work is no longer aligned with priorities.
I want to be careful here: I am not accusing Snowflake of doing anything improper. They bought a company. They are entitled to allocate their engineering budget as they see fit. The structural critique is not about any individual acquirer’s choices. It is about the fact that the PostgreSQL community, as a community, has no mechanism to notice when the funding base for a critical project is about to shift, and no mechanism to do anything about it when the shift happens. The maintainer absorbs the entire cost of the transition, in the form of unpaid maintenance work followed by a job search.
Repeat this pattern for the next decade as the consolidation continues, and you will get more pgBackRest-shaped announcements. Some of them will be about projects you didn’t know you depended on until you suddenly did.
What now: a brief tour of the alternatives
The good news, such as it is, is that PostgreSQL backup is no longer a one-tool category. The ecosystem has moved while we weren’t watching, and PostgreSQL itself has gotten substantially better at this in the last two major releases. Here is the lay of the land at a high level. None of these are drop-in replacements for pgBackRest. All of them require evaluation against your specific operational needs.
pg_basebackup plus pg_combinebackup (built-in)
Since PostgreSQL 17, the combination of pg_basebackup --incremental and pg_combinebackup provides block-level incremental backup natively, reconstructing a synthetic full backup from a chain of incrementals. This is genuinely new and genuinely good. It is also primitive — there is no built-in retention management, no built-in remote storage support beyond what you can script around it, no parallel restore in the pgBackRest sense, and no integrated WAL archiving with the same nice properties. You get the primitive; you build the operational layer yourself, or you find a tool that does.
For small-to-medium deployments where you control the storage layer and can tolerate writing some scripts, this is now a viable answer. It was not a viable answer two years ago.
Barman (EDB)
Barman is the other major incumbent, originally from 2ndQuadrant and now maintained inside EDB. Python-based, full backup/PITR/retention/streaming WAL/cloud storage support. Comparable feature set to pgBackRest at a high level, with different tradeoffs in the specifics.
The political situation is worth noting. Barman is now maintained by the same company that owns 2ndQuadrant’s former staff and that has been the dominant commercial PostgreSQL vendor for years. Whether that’s a stability advantage (one big company will keep funding it) or a different flavor of the same risk (one big company can change its mind) depends on your priors about EDB. It is, at minimum, actively maintained today.
WAL-G
Originally a Yandex project, now community-maintained, written in Go. Supports PostgreSQL plus a long list of other databases. Cloud-storage native. Lower operational overhead than pgBackRest in many respects; less feature-rich in others (the page-checksum-during-backup machinery in particular is a pgBackRest specialty). Active development. Heavy adoption in cloud-native deployments.
This is the strongest current candidate for pgBackRest users who need a feature-comparable replacement and don’t want to bet on EDB. It is not as feature-complete as pgBackRest, and the documentation is less polished, but it is real software with real maintainers and real production deployments.
Cloud-managed backups (RDS, Aurora, Cloud SQL, Azure)
If you are on a managed PostgreSQL service, your provider handles backups, and you do not have a pgBackRest decision to make. You have, instead, a different set of decisions about retention windows, point-in-time recovery granularity, cross-region replication, and the persistent question of whether your provider’s backup is actually a backup or just a snapshot of the same fate as your primary. (It is usually closer to the second than your account rep wants you to believe. Test your restore procedures. Yes, really.)
pg_dump
Logical backup. Useful for migrations, dev/test data refreshes, and small databases. Not a serious answer for PITR at scale. If your “backup strategy” is a nightly pg_dumpall, please reconsider.
What about pgBackRest itself?
The code still works. v2.58.0 is functional, well-tested, and supports up to PostgreSQL 18 (per the project’s “ten versions” policy). If you have it deployed today, it will not stop working tomorrow. What it will stop receiving is bug fixes, security patches, and new-version support. Plan a migration on a timescale measured in months to a year, not in weeks. There is no fire. There is, however, smoke.
A community fork is plausible — the code is MIT-licensed, the architecture is sound, and the userbase is large enough that someone will eventually try. Steele’s request that any fork pick a new name is the right call: a fork without him is a different project, and pretending otherwise would only confuse users about who they are trusting. If a credible fork emerges with credible maintainers and a credible funding model, it deserves a fresh evaluation. Until then, treat pgBackRest as a sunsetting deployment.
The thing to actually take away
David Steele built and maintained one of the most operationally important pieces of PostgreSQL ecosystem software for thirteen years. He was paid for some of that time and not paid for the rest of it. When the funding ran out, he tried to find more, and he couldn’t, and so the project ends. This is not a story about Steele making a wrong choice. He made the right choice, possibly later than he should have. It is a story about a system that produced this outcome as its default behavior, and that will continue to produce this outcome until the people who benefit most from PostgreSQL find a way to fund the people who actually build it.
That is not a problem with a technical solution. It is, in the long run, the only problem in this space that matters.