The editorial argues that PostgreSQL practitioners had long whispered about pgbackrest's bus factor. Despite the project having the technical quality of a well-funded infrastructure team, it had the organizational resilience of a side project — a pattern the editorial identifies as recurring across critical open-source infrastructure.
The editorial emphasizes that this isn't a niche library losing steam — Crunchy Data's PGO Kubernetes operator uses pgbackrest as its default backup engine, meaning every PGO-managed PostgreSQL cluster in production was implicitly depending on David Steele's continued involvement. The tool handled the full spectrum of backup operations including parallel execution, WAL archiving, PITR, encryption, and multi-cloud storage.
Submitted the GitHub repository status change to Hacker News where it scored 403 points with 217 comments, signaling widespread community alarm at the loss of what had become PostgreSQL's most trusted and feature-complete physical backup solution.
The editorial draws explicit parallels to OpenSSL and core-js, framing pgbackrest's maintenance loss as part of a broader pattern where critical infrastructure depends on unpaid or under-supported individual maintainers. It argues backup software is an especially dangerous category for this failure mode because failures are silent until a disaster recovery scenario.
The editorial notes that pgbackrest being written in C already limited the contributor pool, and that the project's high architecture and quality standards meant casual drive-by contributions were rare. David Steele reviewed virtually everything, creating a knowledge and gatekeeping bottleneck that compounded the language barrier.
pgbackrest — the C-based backup and restore tool that became the PostgreSQL community's default recommendation for production workloads — is no longer being actively maintained. The project's GitHub repository at `pgbackrest/pgbackrest` now reflects this status, sending a ripple of concern through the PostgreSQL ecosystem.
The tool was primarily authored and maintained by David Steele, who built pgbackrest into the most feature-complete physical backup solution for PostgreSQL over the course of nearly a decade. pgbackrest handled the full spectrum of backup operations — full, differential, and incremental backups with parallel execution, WAL archiving, point-in-time recovery, encryption at rest, and native support for S3, GCS, and Azure Blob storage. It was, by any reasonable measure, the Swiss Army knife of PostgreSQL backup tooling.
The Hacker News discussion (scoring 403 points, well above the noise floor) reflects the gravity of the situation. This isn't a niche library losing steam — it's the tool that Crunchy Data's Kubernetes operator (PGO) uses as its default backup engine, meaning every PGO-managed PostgreSQL cluster in production was implicitly depending on David Steele's continued involvement.
### The Bus Factor Was Always the Risk
PostgreSQL practitioners have whispered about pgbackrest's bus factor for years. Despite being written in C (which already limits the contributor pool), the project's architecture and quality standards were high enough that casual drive-by contributions were rare. David Steele reviewed virtually everything. The project had the technical quality of a well-funded infrastructure team but the organizational resilience of a side project — a pattern that recurs across critical open-source infrastructure.
This mirrors the broader open-source sustainability crisis that has played out with OpenSSL, core-js, and countless other projects. The difference is that backup software has an unusually high consequence profile. A bug in your CSS framework ships a visual glitch. A bug in your backup tool ships data loss.
### What pgbackrest Did That Others Don't
To understand the migration challenge, you need to understand what made pgbackrest the community default:
- Incremental backups with block-level delta tracking — not just file-level diffs, but actual block-level changes. This meant backup windows for multi-terabyte databases stayed manageable. - Parallel backup and restore — saturating available I/O bandwidth rather than single-threading through a backup. - Built-in backup verification — checksums and integrity validation that didn't require a separate restore-and-check workflow. - Multi-repository support — backup to local disk AND S3 simultaneously, with independent retention policies. - Encryption at rest — without bolting on GPG or relying on storage-layer encryption.
No single alternative covers all of these capabilities today. Barman comes closest on the feature matrix but is Python-based (higher resource overhead) and has a different operational model. WAL-G is faster for cloud-native workloads but lacks the granular configuration and verification features that enterprise users depend on.
### The Crunchy Data Question
Crunchy Data, where David Steele worked, built significant commercial value on top of pgbackrest. Their PGO Kubernetes operator — one of the most widely deployed PostgreSQL operators — uses pgbackrest as the backup engine. The question the community is now asking: will Crunchy Data step up to fund continued maintenance, fork the project, or migrate PGO to an alternative?
This is a consequential decision. If Crunchy Data moves PGO away from pgbackrest, it effectively signals end-of-life for the tool in Kubernetes environments, which is where most new PostgreSQL deployments are happening. If they fund ongoing maintenance, it could revive the project — but that requires finding someone willing and able to maintain a mature C codebase with pgbackrest's quality bar.
### If You're Running pgbackrest Today
Don't panic, but do plan. pgbackrest doesn't stop working because it's unmaintained — your backups will continue to run. The risk surfaces when:
1. PostgreSQL ships a new major version that changes WAL format, catalog structure, or backup APIs. pgbackrest historically shipped compatibility updates within weeks of a new PG release. Without maintenance, that window becomes indefinite. 2. A security vulnerability is discovered in pgbackrest's C code. No maintainer means no patch. 3. Cloud providers change object storage APIs — S3 compatibility isn't static, and Azure/GCS evolve their authentication models regularly.
The practical advice: test your next PostgreSQL major version upgrade against your pgbackrest version in a staging environment before you commit. If it breaks, you need a migration plan, not a hotfix.
### Evaluating Alternatives
Barman (by EDB/2ndQuadrant) is the most mature alternative. It supports PITR, remote backup, incremental backups, and has active corporate backing from the largest PostgreSQL company. The trade-off: it's Python, it has a steeper learning curve for configuration, and its operational model assumes a dedicated backup server rather than pgbackrest's more flexible topology.
WAL-G is the cloud-native choice. It's fast, supports S3/GCS/Azure natively, and has a growing community. It's a strong fit for Kubernetes deployments where you want simple cloud-bucket backups with PITR. The trade-off: fewer features than pgbackrest, less mature verification tooling, and a younger codebase.
pg_basebackup is built into PostgreSQL itself and will never have a maintenance problem — but it also doesn't support incremental backups, parallel operations, or cloud storage without wrapper scripts. It's the fallback, not the solution.
For most teams, the pragmatic move is: start testing Barman or WAL-G in a non-production environment now. Don't wait for your pgbackrest setup to break.
### The Sustainability Angle
If your organization depends on pgbackrest in production, this is the moment to ask whether you've ever contributed to the project — financially or with engineering time. The PostgreSQL ecosystem has historically been generous with its tools but stingy with its funding models. pgbackrest's situation is a direct consequence of the industry treating critical infrastructure as free.
Organizations like the PostgreSQL community and PGXN are exploring better funding and governance models for ecosystem tools. If pgbackrest's lapse pushes more companies toward sustainable open-source funding, that's a silver lining — but it's cold comfort for the DBAs who need working backups next quarter.
The most likely outcomes, in order of probability: a community fork emerges with multiple maintainers (this is what happened with Redis and Valkey), Crunchy Data funds a maintenance team internally, or the community gradually migrates to Barman/WAL-G over the next 12-18 months. The worst outcome — silent bitrot with no clear successor — is unlikely given the project's importance, but it's happened before with tools this critical. The PostgreSQL community has been resilient about these transitions, but resilience has a cost, and that cost is measured in migration hours, re-tested runbooks, and production incidents during the switchover.
"so sad to see this"The source is still available. Maintaining your own copy and/or paying someone to do it is an option.While you're at it, look at all the projects you depend on that you would similarly be sad about losing, and set up those donations today.
Wow! pgbackrest was definitely the premier backup solution for postgres when I last looked at the ecosystem properly.It was the only solution that seemed to take restoring and validating as seriously as “taking a backup” which lead to an unfortunate situation with my employer. (details here: https:&
Wow, this is pretty surprising, I was under the impression that this is the leading PG backup/recovery tool.Anybody know how WAL-G and Barman compare?https://github.com/wal-g/wal-ghttps://github.com/EnterpriseDB/barman
Open Source has worked fine here. The author doesn't find financial support for the work, so they just want to change winds and that's a perfectly fine path forward.If this is really much more than a personal project "for fun, on my leisure time", and it became an actually seriou
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
So sad to see this happening..I had just last year prepared a detailed guide for reliable postgre backups to local volume as well as cloud storage, using pgBackRest, for my own projects.. pgBackRest have worked so well for mehttps://github.com/freakynit/postgre-backup-and-restore