| From: | Christophe Pettus <xof(at)thebuild(dot)com> |
|---|---|
| To: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | pgBackRest maintenance (was Re: Tablespace size in TB) |
| Date: | 2026-05-04 06:45:53 |
| Message-ID: | DEBB18A6-E034-4222-B89A-99F3EB6EAF87@thebuild.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> On May 3, 2026, at 22:55, Ilya Kosmodemiansky <ik(at)dataegret(dot)com> wrote:
> Making a company-branded fork is the easiest (and wrong) step. Planning how to pick up the pgBackRest project or create a sustainable, community-driven fork that re-establishes at least the same reputation requires longer preparation. We all need patience.
Dave was quite clear that someone "picking up the pgBackRest project" was not on the table. I don't think that avenue is open.
I would feel more sanguine about the idea that a new community-suported fork will emerge if there were an existence proof of it happening in the PostgreSQL community. I can't think of one.
We need to tell our customers something, and "the community will ride in and maintain pgBackRest, just you wait" isn't a satisfactory answer. We can tell clients all we want that the current pgBackRest version works just fine, they don't have to change, a community standard version will emerge, and so forth, but that falls on deaf ears. This is a backup tool; it's second only to PostgreSQL itself in the "must work all the time" camp. All they hear is what it says on the repo, which is "pgBackRest is no longer being maintained."
I think it more likely that an entirely new backup tool will emerge, become the de facto community standards, and then we will move off pgBackRest (and its forks) onto that.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2026-05-04 12:23:04 | Re: Support logical replication of DDLs, take2 |
| Previous Message | Ilya Kosmodemiansky | 2026-05-04 05:55:34 | Re: Tablespace size in TB |