On April 27, 2026, David Steele archived the pgBackRest GitHub repository1 and posted a NOTICE OF OBSOLESCENCE2 citing the Crunchy Data sale and his failure to secure sponsorship or employment that would allow continued maintenance. After thirteen years and a final release at v2.58.0, the de facto open-source PostgreSQL backup tool for CrunchyData PGO and the Percona Operator is now read-only. For SREs who built restore SLOs around pgBackRest’s stanza and delta-block model, the alternatives don’t swap in.
The Archive: What Happened on April 27
The archiving was deliberate, not a lapse. Steele’s notice states plainly: “Rather than do the work poorly and/or sporadically, I think it makes more sense to have a hard stop.” The final release, v2.58.0, shipped January 19, 20261. The last commit on the now-read-only repository (684f12c) removed v1 release information. No patch branch, no security response plan, no handoff to a co-maintainer.
The Crunchy Data sale Steele references has not been independently confirmed outside the maintainer’s notice2. What is clear: pgBackRest was, in practice, a one-developer project sustained by Crunchy Data’s payroll. When that arrangement ended, so did the project.
What pgBackRest Does That Alternatives Don’t
pgBackRest’s differentiation is architectural. The user guide3 documents three features that collectively define how operations teams built their backup and restore workflows:
Block-level incremental backup (repo-block): Rather than tracking which files changed since the last full backup, pgBackRest tracks which 4KB blocks within each file changed. For large databases with concentrated write activity, this reduces backup size and I/O without requiring file-level deduplication.
Delta restore (--delta): On restore, pgBackRest compares the SHA-1 hash of each existing block in the data directory against the backup catalog. Blocks that match are skipped. On a large cluster where only a portion of the data has drifted (corruption, partial restore, DR test teardown), this collapses a multi-hour restore significantly.
Stanza-based configuration: A stanza is a named configuration unit binding a PostgreSQL cluster to one or more backup repositories. Stanzas allow a single pgBackRest installation to manage multiple clusters against multiple storage backends (S3, GCS, Azure, local path) with independent retention policies. It is the right abstraction for multi-cluster Kubernetes operators.
These are the primitives on which SRE teams wrote their restore SLO math.
The Alternative Landscape: WAL-G, Barman, and Volume Snapshots
The three realistic successors are WAL-G4, Barman5, and Kubernetes volume snapshots. None is a drop-in replacement.
| Tool | Version (April 2026) | Maintained | Block-level incremental | Delta restore semantics | Language |
|---|---|---|---|---|---|
| pgBackRest | v2.58.0 (final) | No | Yes (repo-block) | Yes (SHA-1 block hash, —delta) | C |
| WAL-G | v3.0.8 | Yes | Partial (delta backup, file-level) | Partial | Go |
| Barman | v3.18.0 | Yes | Not documented | Not documented as equivalent | Python |
| K8s Volume Snapshots | CSI-dependent | Yes | CSI-driver dependent | N/A | N/A |
WAL-G (v3.0.8, January 2026) is the most plausible migration target for teams that need something working quickly. Written in Go, with 2,137+ commits, it supports delta backups, parallel processing, and LZ4/ZSTD/Brotli compression for PostgreSQL. It is actively maintained. The gap is architectural: WAL-G’s delta backup model operates at the file level, not at the block level within files. Restore semantics differ from pgBackRest’s --delta. Whether the performance difference matters depends on write patterns and data directory layout.
Barman v3.18.0 (March 12, 2026) is maintained by EnterpriseDB under GPL 3 and handles remote backup of multiple PostgreSQL servers. The Barman GitHub repository5 does not document block-level incremental or delta-restore semantics equivalent to pgBackRest’s. Teams that chose pgBackRest over Barman for the delta-block performance profile will not find equivalence here.
CloudNativePG is worth naming separately because it already solved this problem. CloudNativePG’s backup architecture6 is built on the Barman Cloud Plugin via CNPG-I and Kubernetes volume snapshots, with native Barman Cloud integration deprecated since v1.26 in favor of the plugin model. CloudNativePG operators have no migration work to do on pgBackRest’s account.
Kubernetes Operator Impact: CrunchyData PGO and Percona
The operators with the most immediate exposure are CrunchyData PGO and the Percona Operator for PostgreSQL.
CrunchyData PGO7 uses pgBackRest as its backup and disaster recovery tool across all supported storage backends: S3, GCS, Azure Blob, and Kubernetes-native storage. pgBackRest is the only backup tool documented in PGO’s current architecture. There is no documented alternative or migration path in the current release.
Percona Operator for PostgreSQL8 uses pgBackRest for scheduled backups, on-demand backups, encryption, async WAL archiving, and retention management. Neither Barman nor WAL-G appear in Percona’s operator documentation.
Both operators will need to decide: maintain a patched fork of pgBackRest, replace the backup backend (a non-trivial operator change), or accept the CVE risk of running unmaintained C code. For teams running managed Postgres through these operators, the decision belongs to the operator maintainers first. No timeline is known as of April 29, 2026.
Migration Reality Check: Re-Architecture, Not a Swap
Migrating from pgBackRest to WAL-G or Barman is not a configuration change.
The stanza abstraction has no direct counterpart in WAL-G. WAL-G is configured per-cluster via environment variables; it has no native model for managing multiple clusters against shared object storage with per-cluster retention policies. Translating a multi-cluster pgBackRest stanza setup to WAL-G requires a new configuration architecture.
Delta restore SLOs require re-benchmarking from scratch. The assumption that a partial restore of a large cluster finishes within a defined window because pgBackRest skips unchanged blocks does not transfer to WAL-G’s file-level delta or Barman’s restore model. Test before committing those numbers to an SLA.
Existing pgBackRest backup catalogs cannot be read by WAL-G or Barman. Migration means starting from a fresh full backup. Any PITR coverage built on pgBackRest’s catalog is stranded in a format only pgBackRest can read, on software that no longer receives patches.
The Fork Question: Will Someone Pick It Up?
Steele’s notice addresses this directly. He noted that fork projects would need to select a new name and build trust from scratch. The codebase is C, which raises the contribution bar relative to the Go and Python alternatives. Thirteen years of incremental feature work, including the block-level incremental architecture, is not a quick audit.
Whether EDB, Percona, or an independent team steps up to fork and maintain the codebase is not yet known as of April 29, 2026. Both EDB and Percona have direct financial exposure through their Kubernetes operators. Percona has a track record of maintaining patched forks of abandoned database tooling.
What the notice makes clear is that this is not a hiatus. v2.58.0 is the last release. CVEs against the C codebase will need to be patched by whoever takes ownership, or they will go unpatched. That tradeoff is survivable in an airgapped environment. It is a different calculation for backup tooling with access to object storage credentials and open network paths.
Frequently Asked Questions
Are CloudNativePG or managed cloud PostgreSQL users affected?
CloudNativePG users are unaffected—it uses the Barman Cloud Plugin via CNPG-I, not pgBackRest. Teams on managed PostgreSQL services (AWS RDS, Azure Database for PostgreSQL, Google Cloud SQL) use vendor-managed backup tooling and are similarly unexposed. The direct impact is limited to self-managed PostgreSQL deployments running pgBackRest directly or through CrunchyData PGO and Percona Operator.
How much more data does WAL-G transfer compared to pgBackRest’s block-level approach?
WAL-G transfers every file containing a changed block, while pgBackRest transfers only the specific 4 KB blocks that differ. PostgreSQL’s default relation segment size is 1 GB—a single modified block could force a 1 GB transfer under WAL-G versus 4 KB under pgBackRest. The gap widens with larger segment sizes and concentrated write patterns in a few large tables.
What should standalone PostgreSQL teams—not running Kubernetes operators—do right now?
These teams have no vendor to absorb migration work. Three immediate steps: inventory which pgBackRest features (repo-block, —delta, stanza) are actually relied upon for restore SLOs; ensure at least one verified full backup exists outside the pgBackRest catalog in case migration to WAL-G or Barman requires starting over; and begin restore-time benchmarking against alternatives before encountering a PostgreSQL version incompatibility the frozen codebase cannot address.
Could CrunchyData PGO or Percona adopt a pluggable backup model like CloudNativePG’s CNPG-I?
CloudNativePG’s CNPG-I plugin interface decouples backup tooling from the operator core, enabling backend swaps without re-architecting the operator. CrunchyData PGO and Percona Operator hard-couple to pgBackRest—pgBackRest is the only documented backup tool for both. Adopting a plugin model would insulate future backup changes from operator release cycles, but designing that interface is a multi-month engineering effort that neither vendor has announced.
Will a future PostgreSQL major version break pgBackRest v2.58.0 backups?
PostgreSQL major versions can introduce on-disk format or protocol changes requiring explicit backup tool support. pgBackRest v2.58.0, frozen in January 2026, will not receive compatibility patches. If a future release changes something pgBackRest depends on, backups could fail silently or produce inconsistent restores with no maintainer to diagnose or fix the issue. Teams on a PostgreSQL upgrade cycle should complete backup tool migration before their next major version upgrade, not after.