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 me
True.. I truly wish wish we had better open-source license and more open-source projects adopt it..
Tiered pricing license... tiering based upon annual company revenues... should start super low for small companies (free for individuals), and jump to thousands of dollars per year for 10+ milion revenue companies.
I understand that this might not fully be in the spirit of open-source, but, what's happening currently is way worse.. where giant companies rip off the hardwork of open-source software maintainers without compsensating them adequately.
Sigh. Bane of my existence is any service which does this.
My org theoretically makes hundreds of millions, unfortunately none of that money is ours. So I get forced into a procurement process for anything that costs more than (ridiculously small limit), and get stuck using the worst in class because it's cheaper.
It would be great if git hub or someone did something to support licenses like this. So procurement was more like a cloud spend. Organizations should be used to paying for products from individuals just like how they do from megacorporations
The project is being abandoned because the maintainer is tired of working for free. They said that they hoped someone would fork it, change the name, and pick up where it was left off.
Why would anyone do that? If the person who was most passionate about it for over a dozen years has given up because it was never worth the trouble; what fool would think things will be different going forward?
I have a moderately sized 2TB production database I have enjoyed using pgBackRest on, and was—this week—going to set it up on another 8TB database we have.
What's the next-closest thing? wal-g? barman? databasus? I only get to cosplay as a DBA.
I can beat you on the timing - I'd never used pgBackRest before, but started setting it up on a project about 2 hours ago, by the time I'd finished the README had been updated.
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 serious product-level project that provides good value in commercial environments for people, there's clearly an opportunity for a for-profit company to step in and cover that niche. But that'd require that users became customers and actually departed from their money to pay for it :)
I guess most will switch instead to asking who's the next project maintainer to work on it, to whom the new bug reports and complaints can continue to be sent for free. But if there's money to be made by using a tool, there should be money paid for using it too. We "just" need to find the new generation of FOSS Financial Sustainability solutions that actually work! Donations don't make the cut.
Are you using WAL archiving? As far as I understand, pgbackrest and Barman can also use direct streaming from the DB (same mechanism as replication), I didn't find any mention of this in the WAL-G documentation.
With WAL archiving you need to wait for a WAL segment to finish before it's backed up. With streaming backups the deadtime is minimized. At least that's as far as I understand this, I didn't get to try this out in practice yet.
> TL;DR: pgBackRest is no longer being maintained. If you fork pgBackRest, please select a new name for your project.
> I imagine at some point pgBackRest will be forked, but that will be a new project with new maintainers, and they will need to build trust the same way we did.
I completely understand having to back out of maintenance on an OSS project, but why also slam the door closed on someone taking over? There may be someone very qualified willing to step up, and that could give your existing users continuity.
This feels analgous to deciding to stop maintaining a community garden, but rather than let your neighbor step up, you decide to salt the ground so it can never grow there again, telling your neighbors "you can pull up my plants and move them, but you can't use all the ground and roots that are already there." It just feels bitter.
I was about to set up Postgres backups with pgbackrest very soon. It looked like the most mature solution for my use case. What I was aiming for was continuous backups to an object storage provider, without a central DB server but the backup tool directly installed on the Postgres server.
I'll have to look at the alternatives again, I think that was mostly WAL-G and Barman. It looks like Barman doesn't support direct backup to object storage, unfortunately. And I find the WAL-G documentation very confusing. What I'm looking for is WAL streaming and object storage support, to minimize the amount of data that can be lost and so I don't have to run my own backup server.
This is exactly what I was setting it up to do this morning. My research came down to this and WAL-G for the same reasons, and I picked pgBackRest over WAL-G because the documentation was clearer.
i wish the guy could have made a paid version so he could have continued it. Unfortunately, most people do not want to financially contribute to open source and especially when that open source project becomes a paid product.
Really sad to see this. I had only recently learnt about this project, and was really impressed by it. I was planning to set it up this weekend (via autobase). I've also been under the impression that it's likely to be what powers the backups in RDS, Cloud SQL, etc., but I may have misunderstood.
From what I can find Postgres 17 [1] introduced incremental backups to pg_basebackup, refined in 18, but nowhere near the full featureset of pgBackRest. Is that what you meant? Having builtin incremental replication to a S3-compatible storage would be great.
> Since Crunchy Data was sold, I have been maintaining pgBackRest and looking for a position that would allow me to continue the work, but so far I have not been successful. Likewise, my efforts to secure sponsorship have also fallen far short of what I need to make the project viable.
So this was the problem, I thought Snowflake would pick up the sponsorship of this project but since it is a competing database it doesn't really make much sense.
I really wish many critical OSS projects get the sponsorship they need to continue.
Otherwise the software industry is in real trouble.
Forking it just passes the buck onto another maintainer with the same problem, this time without the original creator maintaining it.
Very simple. Name it to pgbackrest-AI and add the line:
"AI driven backups with smartest world class models optimizing every byte stored via deep AI analysis."
With that added, a million dollars is just chimp change. YC alone would be adding them to all the seasons multiple times over summer, winter and monsoon etc.
The number of maintainers is always smaller than the number of users for any successful project. GitHub displays the number of contributors as 57, I don't know if that's small or not.
That is exactly gatekeeping, no? You are only entitled to feel sad if you contributed effort or financially, otherwise you aren't allowed to feel.
Why can't others that just used the tool feel sad? It is supposed to be used, it's the whole reason for it to exist; not everyone using it will have technical expertise or money to contribute to it, feeling sad about it when it solved issues for someone is a completely normal response.
It's such a strawman to claim that you cannot be sad if something disappears where you have not financially or you work contributed. Someone can say that they are sad that the Notre Dame burned down even if they haven't personally contributed to Notre Dame.
Something burning down is a tragedy, beyond anyone's control. It's also possible to love something for its beauty, and be sad that a globally historic monument suffered such an act of god that the irreplaceable art and craftsmanship is gone forever.
Something closing down, perhaps because there was not enough money to sustain its continued operation, when tens of thousands or hundreds of thousands of people were using it? That's a perfectly appropriate time to remind folks, "if you like free software, consider donating to help sustain the almost full-time effort it takes to keep packages like this alive."
Op said, "this is sad [because] I've been using this," and the implication is, "I want to keep using this but now I can't because it's gone" and making the connection that "one way to prevent this from happening to other packages you like is to contribute financially."
Why not try to find a successor instead of archiving the repo and forbidding the use of the name? I'm sure with a 3.8k stars repo you'll find competent people willing to continue the work.
Sometimes you want to hang things to your wall, and be done with it.
I'd personally do the same. I wouldn't want to be bothered by the future maintainers' choices and get feedback/flak for it. It's a well-known and well-respected way to cycle the name with a "-ng" or "-nx" prefix to signal that this is the newer project with a different set of maintainers.
Being MIT, while is not my favorite license, doesn't give free license to grab and run with things.
Honestly, in my eyes, 3.8K or 38K stars mean nothing, because Open Source is not about you [0], to begin with.
It is reasonable to ask for a follow-up project/fork to take a different name. Naming your project, e. G., pgbackrest-ng, does not sound too onerous of a requirement and clearly communicates to users that maintainers have changed (see also paperless ng/ngx as good examples of such a change).
Finding a successor is also not easy nor cheap (in regards to time).
You'll also find plenty of potential malware injectors too, and who would want the responsibility of trying to vet a successor and have to work out the difference?
Because you will attract people who will want to take advantage of the trust these 3.8k stars signal to some people, for example, by means of supply chain attacks.
There's no way to know if a new maintainer will live up to whatever standards they've kept to date. Archiving should be the default decision, unless there's formal and elaborate handover.
Those people can just as easily fork it and make a new name then. Otherwise you end up with situations where it's actually an entirely new thing under new developers under the same name. Even riskier in the age of the "AI clean rewrite"
A maintainer that is mainly motivated by the 3.8k stars aspect is probably not the person you want. Working on critical OSS software is fun until it's not, especially when you are not paid for that work.
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 me
https://github.com/freakynit/postgre-backup-and-restore-guid...
Thanks to the author for all the time and effort he put into this project..
I really wish projects like this didn't fall through the cracks and continued to be funded. The struggles of OSS are too real.
True.. I truly wish wish we had better open-source license and more open-source projects adopt it..
Tiered pricing license... tiering based upon annual company revenues... should start super low for small companies (free for individuals), and jump to thousands of dollars per year for 10+ milion revenue companies.
I understand that this might not fully be in the spirit of open-source, but, what's happening currently is way worse.. where giant companies rip off the hardwork of open-source software maintainers without compsensating them adequately.
Sigh. Bane of my existence is any service which does this.
My org theoretically makes hundreds of millions, unfortunately none of that money is ours. So I get forced into a procurement process for anything that costs more than (ridiculously small limit), and get stuck using the worst in class because it's cheaper.
It would be great if git hub or someone did something to support licenses like this. So procurement was more like a cloud spend. Organizations should be used to paying for products from individuals just like how they do from megacorporations
May be inconvenient to you, but the point of licenses like that is that inconvenience to companies that aren't willing to pay for the work.
The project is being abandoned because the maintainer is tired of working for free. They said that they hoped someone would fork it, change the name, and pick up where it was left off.
Why would anyone do that? If the person who was most passionate about it for over a dozen years has given up because it was never worth the trouble; what fool would think things will be different going forward?
This is the curse of OSS.
I have a moderately sized 2TB production database I have enjoyed using pgBackRest on, and was—this week—going to set it up on another 8TB database we have.
What's the next-closest thing? wal-g? barman? databasus? I only get to cosplay as a DBA.
I've used barman on somewhat large-ish DBs (30+ TB), and had no complaints with it. I am a DBRE, if that holds any weight.
I can beat you on the timing - I'd never used pgBackRest before, but started setting it up on a project about 2 hours ago, by the time I'd finished the README had been updated.
databasus does not do PITR.
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 serious product-level project that provides good value in commercial environments for people, there's clearly an opportunity for a for-profit company to step in and cover that niche. But that'd require that users became customers and actually departed from their money to pay for it :)
I guess most will switch instead to asking who's the next project maintainer to work on it, to whom the new bug reports and complaints can continue to be sent for free. But if there's money to be made by using a tool, there should be money paid for using it too. We "just" need to find the new generation of FOSS Financial Sustainability solutions that actually work! Donations don't make the cut.
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-g
https://github.com/EnterpriseDB/barman
We've been happy with WAL-E and now WAL-G (successor). The streaming PITR nature of these won over pgbackrest when we did the analysis ~9 years ago.
Are you using WAL archiving? As far as I understand, pgbackrest and Barman can also use direct streaming from the DB (same mechanism as replication), I didn't find any mention of this in the WAL-G documentation.
With WAL archiving you need to wait for a WAL segment to finish before it's backed up. With streaming backups the deadtime is minimized. At least that's as far as I understand this, I didn't get to try this out in practice yet.
>Wow, this is pretty surprising, I was under the impression that this is the leading PG backup/recovery tool.
https://xkcd.com/2347/
pgbackrest is the most versatile piece of backup technology for PostgreSQL and in my experience the other products do not come close.
I am therefore quite sad to see this happen. It won't be easy to get feature parity with this great product.
I sincerely hope this is a reversible decision, or perhaps the postgres project could even absorb it into contrib.
> TL;DR: pgBackRest is no longer being maintained. If you fork pgBackRest, please select a new name for your project.
> I imagine at some point pgBackRest will be forked, but that will be a new project with new maintainers, and they will need to build trust the same way we did.
I completely understand having to back out of maintenance on an OSS project, but why also slam the door closed on someone taking over? There may be someone very qualified willing to step up, and that could give your existing users continuity.
This feels analgous to deciding to stop maintaining a community garden, but rather than let your neighbor step up, you decide to salt the ground so it can never grow there again, telling your neighbors "you can pull up my plants and move them, but you can't use all the ground and roots that are already there." It just feels bitter.
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://blog.dijit.sh/that-time-my-manager-spend-1m-on-a-bac...)
This is really a major loss. :(
I was about to set up Postgres backups with pgbackrest very soon. It looked like the most mature solution for my use case. What I was aiming for was continuous backups to an object storage provider, without a central DB server but the backup tool directly installed on the Postgres server.
I'll have to look at the alternatives again, I think that was mostly WAL-G and Barman. It looks like Barman doesn't support direct backup to object storage, unfortunately. And I find the WAL-G documentation very confusing. What I'm looking for is WAL streaming and object storage support, to minimize the amount of data that can be lost and so I don't have to run my own backup server.
This is exactly what I was setting it up to do this morning. My research came down to this and WAL-G for the same reasons, and I picked pgBackRest over WAL-G because the documentation was clearer.
i wish the guy could have made a paid version so he could have continued it. Unfortunately, most people do not want to financially contribute to open source and especially when that open source project becomes a paid product.
I use pgbackrest for some databases in production, and it has been VERY good.
Really sad to see this. I had only recently learnt about this project, and was really impressed by it. I was planning to set it up this weekend (via autobase). I've also been under the impression that it's likely to be what powers the backups in RDS, Cloud SQL, etc., but I may have misunderstood.
Ah, sad to read this. Does anyone know of good alternatives?
Postgres has built-in backups starting with version 18.
From what I can find Postgres 17 [1] introduced incremental backups to pg_basebackup, refined in 18, but nowhere near the full featureset of pgBackRest. Is that what you meant? Having builtin incremental replication to a S3-compatible storage would be great.
[1]: https://www.postgresql.org/docs/release/17.0/#:~:text=pg%5Fb...
been using databasus(https://github.com/databasus/databasus) works pretty well so far.
So sad. We have been using this amazing project extensively
> Since Crunchy Data was sold, I have been maintaining pgBackRest and looking for a position that would allow me to continue the work, but so far I have not been successful. Likewise, my efforts to secure sponsorship have also fallen far short of what I need to make the project viable.
So this was the problem, I thought Snowflake would pick up the sponsorship of this project but since it is a competing database it doesn't really make much sense.
I really wish many critical OSS projects get the sponsorship they need to continue.
Otherwise the software industry is in real trouble.
Forking it just passes the buck onto another maintainer with the same problem, this time without the original creator maintaining it.
Very simple. Name it to pgbackrest-AI and add the line:
"AI driven backups with smartest world class models optimizing every byte stored via deep AI analysis."
With that added, a million dollars is just chimp change. YC alone would be adding them to all the seasons multiple times over summer, winter and monsoon etc.
Waiting for all the C-level execs saying that "anyway this is not needed, we're going to vibe-code a solution to our production database backups" lol
The backups will then be hyper-optimized from three hours down to 5 minutes using devnull compression technologies. Its super effective!
Why even waste all this time and money on backups in the first place? Just don't make mistakes.
Only for their AI to delete the production database and all the backups, and be forced to write an apology.
https://news.ycombinator.com/item?id=47911524
Sorry to hear this. Well done for maintaining a successful project for so long.
Mentioned this on X but CockroachDB should sponsor this - their audience is Postgres people and open source contributions can be great marketing.
I have recently configured pgbackrest for our app. :(
Plenty of comments of "So sad I have been using this".
How many actually contributed back to keep it going?
The number of maintainers is always smaller than the number of users for any successful project. GitHub displays the number of contributors as 57, I don't know if that's small or not.
I am not sure why are you gatekeeping this? People can't comment now that they are sad because of what happened?
Gatekeeping?!?
Those that paid, or did any kind of contributions upstream are entitled to be sad.
Others should consider this is what happens to that lego piece in Nebraska, when no one contributes, and everyone uses it.
That is exactly gatekeeping, no? You are only entitled to feel sad if you contributed effort or financially, otherwise you aren't allowed to feel.
Why can't others that just used the tool feel sad? It is supposed to be used, it's the whole reason for it to exist; not everyone using it will have technical expertise or money to contribute to it, feeling sad about it when it solved issues for someone is a completely normal response.
It's such a strawman to claim that you cannot be sad if something disappears where you have not financially or you work contributed. Someone can say that they are sad that the Notre Dame burned down even if they haven't personally contributed to Notre Dame.
That comparison is fallacious too, I think.
Something burning down is a tragedy, beyond anyone's control. It's also possible to love something for its beauty, and be sad that a globally historic monument suffered such an act of god that the irreplaceable art and craftsmanship is gone forever.
Something closing down, perhaps because there was not enough money to sustain its continued operation, when tens of thousands or hundreds of thousands of people were using it? That's a perfectly appropriate time to remind folks, "if you like free software, consider donating to help sustain the almost full-time effort it takes to keep packages like this alive."
Op said, "this is sad [because] I've been using this," and the implication is, "I want to keep using this but now I can't because it's gone" and making the connection that "one way to prevent this from happening to other packages you like is to contribute financially."
Alright, take a park closing then. Can you be sad about that if you haven't personally raised money to finance the park?
Why not try to find a successor instead of archiving the repo and forbidding the use of the name? I'm sure with a 3.8k stars repo you'll find competent people willing to continue the work.
Sometimes you want to hang things to your wall, and be done with it.
I'd personally do the same. I wouldn't want to be bothered by the future maintainers' choices and get feedback/flak for it. It's a well-known and well-respected way to cycle the name with a "-ng" or "-nx" prefix to signal that this is the newer project with a different set of maintainers.
Being MIT, while is not my favorite license, doesn't give free license to grab and run with things.
Honestly, in my eyes, 3.8K or 38K stars mean nothing, because Open Source is not about you [0], to begin with.
[0]: https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
It is reasonable to ask for a follow-up project/fork to take a different name. Naming your project, e. G., pgbackrest-ng, does not sound too onerous of a requirement and clearly communicates to users that maintainers have changed (see also paperless ng/ngx as good examples of such a change).
Finding a successor is also not easy nor cheap (in regards to time).
You'll also find plenty of potential malware injectors too, and who would want the responsibility of trying to vet a successor and have to work out the difference?
Because you will attract people who will want to take advantage of the trust these 3.8k stars signal to some people, for example, by means of supply chain attacks.
There's no way to know if a new maintainer will live up to whatever standards they've kept to date. Archiving should be the default decision, unless there's formal and elaborate handover.
Because that rug pulls your users.
3.8k stars and the name is years of built up trust with you, not with the person you gave it to.
They are not really forbidding the use of the name (unless they have registered a trademark), they probably simply want to avoid confusion.
Those people can just as easily fork it and make a new name then. Otherwise you end up with situations where it's actually an entirely new thing under new developers under the same name. Even riskier in the age of the "AI clean rewrite"
A maintainer that is mainly motivated by the 3.8k stars aspect is probably not the person you want. Working on critical OSS software is fun until it's not, especially when you are not paid for that work.