When the foundation is right, it can be about craftsmanship again
Interim via OptimaData is not placement. It is working together on substance. We have our own staffing agency. A separate…
Update May 4th
The story has taken an unexpected turn. David Steele has announced today that it now appears very likely that he will be able to continue pgBackRest after all, this time funded by a coalition of sponsors, ensuring that a single acquisition can never again determine the project’s continuity. He expects to make a definitive announcement before the end of this week.
In the meantime, a few companies had already moved quickly to announce their own forks (with good intentions, no doubt. But it does raise a question: could that energy and those resources have been better spent supporting the original project? A forest of forks) each with its own patches, its own roadmap, and uncertainty about which version ends up in the official packages, is exactly the scenario the community feared most.
Our article from April 28th remains below as a factual account of the original announcement. The situation has changed; the lesson has not: structural dependency on a single party deserves ongoing attention, regardless of how this plays out.
We will keep you updated once Steele publishes his final decision.
Background
pgBackRest has been one of the most widely used backup and restore tools for PostgreSQL for over a decade. The tool supports full, differential, and incremental backups, WAL archiving, parallel processing, and integration with object stores such as S3 and Azure Blob Storage.
Development was sponsored for years by Crunchy Data. Following the acquisition of Crunchy Data, that sponsorship ceased. Steele has since attempted to find alternative funding or a suitable role, but without success. His decision to stop follows directly from that.
The last stable release is v2.58.0 (January 2026). No new versions, bug fixes, or security patches will be released.
What does this mean in practice?
pgBackRest is deeply integrated into many PostgreSQL production environments (via Ansible, Kubernetes operators, cloud platforms, and managed cloud databases). The tool will continue to function in its current configuration, but:
- New PostgreSQL versions will no longer be supported
- Security vulnerabilities will no longer be patched
- Bugs will no longer be resolved
- Community support from the original maintainer lapses
There is no reason for immediate panic or urgent action, the tool will continue to do what it needs to do for now. However, for organisations actively using pgBackRest, it is wise to assess in the short term where the tool is in use, what a sustainable and reliable alternative looks like, and which migration strategy is appropriate.
Alternatives
The most well-known alternatives are:
- Barman (EDB/2ndQuadrant): widely deployed, actively maintained, and very stable; suitable for centralised backup architectures and enterprise environments
- WAL-G: cloud-native and high-performance; excellent integration with object storage (S3, GCS, Azure), ideal for large datasets and modern infrastructures
- Kubernetes-native solutions: integrated backup strategies within container platforms; relevant for cloud-native deployments. For example, CloudNativePG (the most widely adopted Kubernetes operator) uses Barman, and Zalando uses pg_basebackup and WAL-G.
And of course:
- pg_dump / pg_basebackup (standard PostgreSQL tooling): basic options for logical and physical backups respectively; suitable for simple use cases or as building blocks within custom solutions
- Custom solutions (pg_basebackup + WAL archiving): maximum control and flexibility; suitable for organisations with specific requirements and sufficient PostgreSQL expertise
Less well-known alternatives (but growing in maturity) include:
- pg_probackup (Postgres Pro): a mature tool with advanced features such as incremental backups and page-level recovery; suitable for complex PostgreSQL environments
- pgmoneta: a modern, actively developed project; lightweight and performant, with a clear focus on simplicity and future-proofing
Commercial alternatives are also available:
- Enterprise backup suites (e.g. Veeam, Commvault): integrate PostgreSQL into broader backup, compliance, and governance strategies; suitable for larger organisations
The right choice depends on the specific architecture, RPO/RTO requirements, and the platform landscape of the organisation.
Broader impact on the PostgreSQL ecosystem
The disappearance of pgBackRest affects more than just the tool itself. It exposes a vulnerability that has long been simmering in the open source world: critical tools are carried by a single person or a single sponsor, and when that disappears, the entire community faces a problem.
Within the PostgreSQL community, concerned voices are already being heard. It is expected that multiple forks of pgBackRest will emerge quickly, but that does not solve the underlying problem. Multiple forks, inconsistent patches, uncertainty about which version ends up in the official RPM and DEB packages: it only makes an already complex situation more confusing.
More and more voices in the community are therefore calling for a structural solution: an umbrella organisation (comparable to the Apache Software Foundation) that sustainably houses critical tools, ensures funding, and provides maintainers with security. No dependency on a single company that can be acquired, or a CEO who can reset budgets.
It is a discussion that is gaining serious momentum and in a broader context. Because pgBackRest is likely not the last project to be left without support.
Need help assessing your environment?
As a PostgreSQL specialist with years of experience in managing production databases, we are happy to help you map out the impact and determine the right replacement strategy. Contact us for a no-obligation conversation.
