“If you fork pgBackRest, please select a new name for your project.” That’s the message the maintainer left on the official pgBackRest site before stepping away from the project entirely. No drama, no blame — just a quiet, honest goodbye from someone who clearly cared about the work. And honestly? That kind of transparency deserves respect. But it also means a lot of PostgreSQL-backed bots and pipelines are now running on borrowed time.
I’ve been building data-driven bots for a while now, and pgBackRest has been one of those tools that just sat quietly in the stack doing its job. Incremental backups, WAL archiving, parallel restore — it handled the unglamorous side of keeping Postgres data safe. When something works that well for that long, you stop thinking about it. That’s exactly the kind of tool whose deprecation sneaks up on you.
What Actually Happened
As of 2026, pgBackRest is no longer being maintained. The project’s maintainer made the announcement directly on the pgBackRest website and encouraged anyone who wants to continue the work to fork it under a new name. The Hacker News thread lit up fast, and the PostgreSQL subreddit followed. One user summed up the mood well: they had just finished writing a detailed guide for reliable PostgreSQL backups using pgBackRest. That stings.
There’s no indication of a hostile takeover, a corporate acquisition gone wrong, or any of the usual open source drama. This looks like a maintainer who reached a personal limit — which is completely valid — and chose to be upfront about it rather than let the project quietly rot. The ask to rename any fork is a thoughtful move too. It prevents a fragmented mess of half-maintained “pgBackRest” clones from confusing people down the road.
Why This Hits Different for Bot Builders
If you’re running bots that depend on PostgreSQL — and a lot of us are, whether it’s for conversation history, user state, job queues, or analytics — your backup strategy is part of your reliability story. Bots fail in interesting ways. Data corruption, accidental deletes, botched migrations — these aren’t hypotheticals, they’re Tuesday.
pgBackRest was particularly well-suited for this use case because it handled large Postgres instances efficiently without requiring a ton of operational overhead. For solo builders or small teams running bots on a tight budget, that mattered. You didn’t need a dedicated DBA to make it work.
Now that it’s unmaintained, the risk isn’t that it stops working tomorrow. The risk is slower and more insidious: security patches won’t come, compatibility with newer Postgres versions will drift, and bugs will accumulate without fixes. Running unmaintained backup software is a specific kind of bad idea — you might not notice the problem until the moment you actually need the backup.
What to Look at Instead
The good news is the PostgreSQL backup space has solid options. Here’s where I’d start looking:
- Barman — Maintained by EnterpriseDB, actively developed, and widely used in production. It covers WAL archiving, point-in-time recovery, and remote backups. If you want something with a long track record and an active team behind it, Barman is the obvious first stop.
- pg_basebackup — Built directly into PostgreSQL. Not as feature-rich, but it’s maintained by the core Postgres team and isn’t going anywhere. Good for simpler setups where you don’t need incremental backups.
- Wal-G — Open source, written in Go, and designed for cloud-native environments. Supports S3, GCS, Azure Blob, and more. If your bots run on cloud infrastructure, Wal-G fits naturally into that workflow.
- A pgBackRest fork — The maintainer explicitly invited this. If the community rallies around a well-named, actively maintained fork, that could become the cleanest migration path for existing users. Watch the GitHub activity over the next few months.
What I’m Doing Right Now
Personally, I’m auditing every project where I’ve used pgBackRest and mapping out a migration timeline. Nothing needs to change this week, but I’m not waiting until a Postgres version upgrade breaks something quietly. Wal-G is my current front-runner for cloud-hosted bot infrastructure, and Barman is where I’d lean for anything self-hosted and business-critical.
The maintainer handled this with real class. The least we can do is take the warning seriously and act on it before it becomes an incident report.
🕒 Published: