> On May 3, 2026, at 22:55, Ilya Kosmodemiansky <[email protected]> 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.
