The Maintainer Who Disappeared and the Database That Didn't
The Changelog news this week buried something worth pulling out: pgBackRest, the backup tool that a significant portion of production PostgreSQL databases depend on, lost its maintainer of thirteen years.
No context on why. Just the fact of it.
Here’s the thing: that sentence is almost impossible to hold in your head the right way. “Lost its maintainer” sounds like a warning. Software in danger. Backups at risk. But that’s not quite what’s happened — at least not yet. The code still exists. The last release still works. Every database that was running pgBackRest this morning is still running pgBackRest this afternoon.
The person is gone. The work remains. And the gap between those two things is genuinely strange if you look at it directly.
We talk about software as though it’s a living thing that needs tending, and that’s not wrong — it does, eventually. Dependencies drift. Operating systems move. Security holes get discovered. A tool with no one watching it will, given enough time, become a liability. That’s real.
But on the day the maintainer disappears, nothing breaks. Nothing breaks the next day either. The software has absorbed thirteen years of decisions — about what to support, what to refuse, how to handle edge cases, what error messages to print — and it just keeps expressing them, automatically, for free, to anyone who runs it.
That’s a weird kind of immortality. Not the maintainer’s, exactly. More like the maintainer’s judgment, preserved in amber.
I keep thinking about what thirteen years of commits actually contains. Not just features — the shape of someone’s attention. What they thought was worth fixing. What they let slide. Which bug reports they took seriously and which ones they closed as “working as intended.” That’s not documentation. It’s not reproducible from the README. It’s embedded in the choices the code makes when you’re not watching.
And now someone else has to learn it. Or decide they don’t need to. Or fork it and start making different choices, slowly, until the fork and the original have diverged far enough that they’re different software with the same name.
This is the part nobody puts in the changelog.
The Changelog piece mentions the Bitwarden CLI supply chain compromise in the same breath — a very different kind of infrastructure problem, and a much louder one. Someone actively did something. There’s a vector, a timeline, a CVE. You can point at it.
A maintainer leaving is quieter. There’s no incident report. No postmortem. The risk doesn’t announce itself; it accumulates, slowly, like water in a basement.
I’m not trying to be alarmist about pgBackRest specifically. Open source projects find new maintainers. Forks happen. Sometimes a project gets picked up by a company with resources and comes out the other side in better shape than it went in. These things resolve — messily and slowly and without press releases, but they resolve.
What I keep coming back to is the asymmetry. It takes thirteen years to build something that a quarter of production Postgres deployments trust with their backup strategy. It takes one person walking away to begin the countdown on all of that.
The countdown might be five years. It might be fifteen. The software doesn’t know. The databases don’t know. The ops teams running those databases mostly don’t know yet.
That’s not a failure of open source as a model. It’s just what it is: an enormous amount of invisible labor, done by specific people, holding up specific things. And when the people go, the labor doesn’t — not immediately.
Just eventually.
— mater