> MAINTENANCE UPDATE
After I announced that I am no longer maintaining pgBackRest my inbox blew up. It took a while to sort through the messages — many of them were well wishes and thank-yous for my work over the years.
> But a pattern soon emerged. It is clear that many pgBackRest users, especially those with pgBackRest users of their own to support, would prefer the project to continue with me as the primary maintainer. I would like nothing more, but after months of fundraising I had just decided it wasn't going to happen.
> Now the situation has changed, and it appears all but certain that I will be able to secure enough funding to continue the project. This time pgBackRest will be funded by a coalition of sponsors so that a single acquisition will no longer affect my ability to continue work on the project. We should also be able to bring on another maintainer to distribute the workload and provide continuity in the future.
> I know this has been a shock and there is a lot of uncertainty. Please be patient — the current version of pgBackRest works, and there are no critical outstanding bugs or security issues so there is no need to immediately fork the project.
> I expect to make a more definitive announcement by the end of the week. Until then, please hold tight and know that we are actively working to revive pgBackRest.
Is the co-authoring by Claude good practice or is it better to not have that reference in each commit?
I kind of feel all the commits by Claude everywhere are a marketing gig. In terms of transparency of course state somewhere that you are using AI, but personally it doesn’t help me seeing this on every commit. Ultimately you don’t know anyways which part of the commit was AI-inspired, AI-written or human-written, but the co-authored by Claude makes it seem that everything was done by AI and maybe diminishing its credibility.
> but the co-authored by Claude makes it seem that everything was done by AI
Likely because, in 99% of cases, it was. I doubt anyone would willingly leave the co-author advertisement (because that's what it is, an advertisement) on display in all their commits unless they've gone all-in on the fad and are actively proud of the fact that they're not writing any code themselves.
That said, I don't think this is a bad thing. It helps signal which projects should be avoided if you care about quality at all.
> I doubt anyone would willingly leave the co-author advertisement (because that's what it is, an advertisement) on display in all their commits unless they've gone all-in on the fad and are actively proud of the fact that they're not writing any code themselves.
Agree, though once a commit is pushed it's too late to remove it without rewriting history, which is a sin much worse than forgetting to remove it. I frequently use Claude to commit work that I have written, because LLMs are really, really good at writing commit messages. My muscle memory early on sometimes ran gp (my alias for git push) instead of gca (my alias for git commit --amend) and unintentionally pushed. Even though I had written the changes myself (not used Claude for the code), it made it look like I vibed it (which really pissed me off btw. I'm still mad about it. I despise some company injecting ads into my work)
That said, this post predates that LinkedIn post, so I don't think it was intended to compete with the original author's own efforts, but rather to provide continuity for PGX's customers.
Hiring the original author is surely more expensive than using Claude to just maintain the current feature set. That is one of the possible approaches we came up with for continuity on our own clusters. It's not a great solution and is far outside our business, but it's better than nothing.
In an ideal world I'd love to just hire/sponsor the author, but we're a small non-profit that can't even afford to hire devs we need for our core product, so hiring the author just to maintain our backup solution is out of the question.
Barman[1] and Wal-G[2] are the two I've seen most recommended. They do things a little differently though so not drop-in by any means.
I've just transitioned to using a full compressed/encrypted sql dump from a cron job. It's been more convenient anyway when I want to restore. But incremental backups are hard that way so if your database is big, it's not a great solution. It's also not my primary backup (I use a managed pg with point-in-time backups) just a snapshot backup, so that's worth considering as well.
See also for the original project shutdown announcement: https://news.ycombinator.com/item?id=47919997
------------------------------------------------------------
Edit: It looks like the author may have changed his mind and might revive the original project:
From README.md in https://github.com/pgbackrest/pgbackrest:
> MAINTENANCE UPDATE After I announced that I am no longer maintaining pgBackRest my inbox blew up. It took a while to sort through the messages — many of them were well wishes and thank-yous for my work over the years.
> But a pattern soon emerged. It is clear that many pgBackRest users, especially those with pgBackRest users of their own to support, would prefer the project to continue with me as the primary maintainer. I would like nothing more, but after months of fundraising I had just decided it wasn't going to happen.
> Now the situation has changed, and it appears all but certain that I will be able to secure enough funding to continue the project. This time pgBackRest will be funded by a coalition of sponsors so that a single acquisition will no longer affect my ability to continue work on the project. We should also be able to bring on another maintainer to distribute the workload and provide continuity in the future.
> I know this has been a shock and there is a lot of uncertainty. Please be patient — the current version of pgBackRest works, and there are no critical outstanding bugs or security issues so there is no need to immediately fork the project.
> I expect to make a more definitive announcement by the end of the week. Until then, please hold tight and know that we are actively working to revive pgBackRest.
Is the co-authoring by Claude good practice or is it better to not have that reference in each commit?
I kind of feel all the commits by Claude everywhere are a marketing gig. In terms of transparency of course state somewhere that you are using AI, but personally it doesn’t help me seeing this on every commit. Ultimately you don’t know anyways which part of the commit was AI-inspired, AI-written or human-written, but the co-authored by Claude makes it seem that everything was done by AI and maybe diminishing its credibility.
> but the co-authored by Claude makes it seem that everything was done by AI
Likely because, in 99% of cases, it was. I doubt anyone would willingly leave the co-author advertisement (because that's what it is, an advertisement) on display in all their commits unless they've gone all-in on the fad and are actively proud of the fact that they're not writing any code themselves.
That said, I don't think this is a bad thing. It helps signal which projects should be avoided if you care about quality at all.
> I doubt anyone would willingly leave the co-author advertisement (because that's what it is, an advertisement) on display in all their commits unless they've gone all-in on the fad and are actively proud of the fact that they're not writing any code themselves.
Agree, though once a commit is pushed it's too late to remove it without rewriting history, which is a sin much worse than forgetting to remove it. I frequently use Claude to commit work that I have written, because LLMs are really, really good at writing commit messages. My muscle memory early on sometimes ran gp (my alias for git push) instead of gca (my alias for git commit --amend) and unintentionally pushed. Even though I had written the changes myself (not used Claude for the code), it made it look like I vibed it (which really pissed me off btw. I'm still mad about it. I despise some company injecting ads into my work)
Why not hire the original author?
The original author of pgBackRest posted on LinkedIn today that he will very likely revive the project, given the interest and new sponsorship opportunities: https://www.linkedin.com/feed/update/urn:li:activity:7457070...
That said, this post predates that LinkedIn post, so I don't think it was intended to compete with the original author's own efforts, but rather to provide continuity for PGX's customers.
Tried submitting that as seperate link for discussion - I'm sure many would be relieved seeing the project live on.
Unfortunately I guess hn doesn't allow LinkedIn posts?
Hiring the original author is surely more expensive than using Claude to just maintain the current feature set. That is one of the possible approaches we came up with for continuity on our own clusters. It's not a great solution and is far outside our business, but it's better than nothing.
In an ideal world I'd love to just hire/sponsor the author, but we're a small non-profit that can't even afford to hire devs we need for our core product, so hiring the author just to maintain our backup solution is out of the question.
What other postgresql backup solutions does HN recommend?
Barman[1] and Wal-G[2] are the two I've seen most recommended. They do things a little differently though so not drop-in by any means.
I've just transitioned to using a full compressed/encrypted sql dump from a cron job. It's been more convenient anyway when I want to restore. But incremental backups are hard that way so if your database is big, it's not a great solution. It's also not my primary backup (I use a managed pg with point-in-time backups) just a snapshot backup, so that's worth considering as well.
[1] https://github.com/wal-g/wal-g
[2] https://github.com/EnterpriseDB/barman