pgBackRest生死七日逆转:开源维护者如何用“消失”倒逼市场定价
几天前,PostgreSQL生态的顶级开源备份方案pgBackRest突然宣布停止维护,整个社区为之震动。尽管Pigsty项目同样深度依赖pgBackRest,但并未陷入恐慌——如此关键的基础设施,PostgreSQL生态绝不可能任其消亡。当时甚至承诺若无人接手将主动接盘,如今看来这一备用方案已无需启动。
David Steele在GitHub README发布“维护动态”:归档公告发布后,他的邮箱被海量邮件淹没。众多用户与厂商表达强烈挽留意愿,他本人也倾向继续维护。更关键的是,由多家赞助商组成的资金联盟已基本谈妥,几乎可以确定将获得足额资金支持继续pgBackRest的开发。

预计本周结束前将发布更明确的正式公告。从归档到逆转,仅仅七天。
此事的精髓不在于“开源社区充满爱心”这类空泛感慨。真正值得关注的是:当一项关键开源基础设施被维护者推向死亡边缘时,市场终于开始为其定价。
这是一次极为纯粹的开源公地悲剧倒逼定价实验。
七日时间线全复盘
先把关键节点梳理清楚。
4月27日,David Steele同时在GitHub和LinkedIn宣布停止维护pgBackRest并归档仓库。声明措辞克制,既无抱怨也未甩锅,仅强调两点:一是允许分叉但不得继续使用pgBackRest名称;二是归档不代表生命周期终结,现有代码可用,运行中的部署不会立即崩溃。
第一条声明尤为重要。备份工具并非普通玩具,而是供应链攻击的高价值目标。一个继承原品牌信任度的分叉若落入恶意之手,风险远超想象。要求更名是David离场时最负责任的安排。
同日,Christophe Pettus在thebuild.com发表《Notice of Obsolescence》,给出冷静判断:应将pgBackRest视为“落日部署”,等待可信分叉出现后再重新评估。
同日,Lætitia Avrot发布《pgBackRest is dead. Now what?》,标题直截了当。她的措辞更为尖锐:AI淘金热潮已彻底改变企业预算优先级。大公司愿意为内存、GPU、token一掷千金,却不愿为保障数据库灾难恢复的人付费。
这番话刺耳,却道破现实。
4月28日,Percona迅速响应。Jan Wieremjewicz发表《pgBackRest is archived, what now?》,承诺Percona将继续支持pgBackRest,但呼吁暂勿急于分叉。他们正与其他厂商商讨联合维护或基金会托管方案。文中透露关键信息:Jan在归档前一周的PGConf.DE演讲中曾引用David提出的透明出资模型,希望将维护成本分摊给多家依赖方。
此举至关重要。Percona并未宣布独占接盘,也未抢先分叉,而是率先呼吁协同。对商业供应商而言,这种克制实属罕见。
但无人及时响应。
换言之,David并非未尝试“温和定价”,只是无人买账,最终只能走向归档。
4月30日,Percona再发《Open source doesn’t die. It gets unfunded.》,将问题挑明:pgBackRest并非生命终结,而是维护资金断裂;Percona与其他公司正幕后推动解决方案。
5月1日,PGX抢先行动。Christophe Pettus旗下的PGX Inc.发布《pgxbackup: Continuity Support for pgBackRest》,将pgBackRest分叉为pgxbackup,定位专为其支持客户提供连续性版本,仅修复关键bug并兼容新PG版本。
此举合理却暗藏微妙。Percona刚呼吁“别急着分叉”,PGX三天后就推出分叉。不能指责Pettus不负责任——他必须对客户负责;但这恰恰说明所谓的“社区协调”极其脆弱。只要有一家厂商失去耐心,双轨预期立刻形成。
5月4日前后,David发布维护更新:赞助联盟基本成型,资金大概率到位。他还在寻找另一位维护者分担工作,避免项目再次沦为单点故障。
至此,逆转完成。
当年Linux基金会响应Redis协议变更、发起Valkey,按自然日算约八天,按工作日算约六天。pgBackRest此次无基金会介入、无许可证战争、无共同敌人,仅凭PG圈内协调,耗时七天。
这个速度已属罕见。
谁在为续命买单:公开信号与推测
正式赞助名单尚未公布,但现有信号已能勾勒大致轮廓。
Supabase是目前最可能被视作核心金主。
根据pgBackRest官网及README的赞助商列表,当前赞助商正是Supabase。更关键的是,Supabase在4月的Developer Update - April 2026中宣布开源Multigres Kubernetes operator,该系统直接内置pgBackRest的PITR备份功能。
这已超越“支持开源”范畴,属于产品路线深度绑定。当你将未来押注在某个备份工具上,而该工具突然失去维护者时,不出资谁出资?
以Supabase当前的估值与融资规模,供养一位pgBackRest核心维护者根本不是资金问题,而是是否愿意承担责任的问题。至于它是否为联盟中最大出资方,仍需等待正式公告。
Percona极可能是核心协调方。 Percona已公开承诺继续支持pgBackRest,且其Percona Distribution for PostgreSQL长期将pgBackRest作为推荐备份方案。客户SLA绑定于此,不可能袖手旁观。但具体出资金额与方式,同样待正式披露。目前其角色更像此次协调的组织者之一。
Cybertec、Timescale、Resonate均有可能参与。 Cybertec的容器化PG产品使用pgBackRest;Lætitia的文章也专门指出Cybertec与Data Egret拥有可临时处理pgBackRest问题的专家。 Timescale拥有公开分叉,这是依赖或评估信号,但不足以单独证明Timescale Cloud的备份链路深度绑定pgBackRest。其具备出资能力,但历史上对上游开源基础设施的投入不算特别主动,因此无法完全确定。
Resonate作为历史赞助方且有David Steele过往工作痕迹,回归小额赞助非常合理。
真正值得关注的是AWS、Google Cloud、Azure等云巨头是否会出现在赞助名单中。若缺席也不意外,大概率仍是PG圈内自掏腰包拯救自家工具。最赚钱者继续沉默,最依赖者挺身而出。
这正是开源世界最熟悉的荒诞现实。
“逼定价”的本质
David Steele到底做了什么?核心在于:他将一个所有人假装免费的服务,重新摆回明码标价的柜台。
归档之前,pgBackRest的状态极具代表性:人人皆知其重要性,人人都在使用,人人默认“它将永远存在”。Crunchy Data曾供养David,大家便将此视为免费午餐。
David曾提出透明出资模型,希望分摊维护成本;Percona的Jan Wieremjewicz在PGConf.DE演讲中也引用过该模型。为何无人及时响应?
因为项目还活着。
活着的东西难以要到资金。你说“我快撑不住了”,对方会说“辛苦了,我们内部评估一下”。你说“再不出钱项目就没了”,对方会说“理解,我们看看下个季度预算”。
反正代码还在,issue还能提,PR还能等,DBA半夜出问题还能上GitHub翻文档。
直到仓库归档。
归档后,所有依赖pgBackRest的企业被迫计算一笔简单账目:
•迁移至Barman或WAL-G,需重做备份恢复流程并重新演练灾备。•内部自行分叉,需供养精通PG、备份技术、C和Perl的高级工程师。•多家联合出资,让David继续维护主线。
第三种方案最便宜。
这便是逼定价。它并非传统勒索。代码采用MIT协议,任何人可分叉、可继续使用。David未将代码封锁,也未通过修改协议征税。他能收回的,唯有自己的时间与信誉。
然而在开源基础设施领域,维护者的时间与信誉恰恰是最昂贵的部分。
Redis/Valkey、HashiCorp Terraform/OpenTofu、Elastic/OpenSearch等事件,均通过商标与协议作为杠杆,结果社区被迫分叉,自身也元气大伤。pgBackRest此次恰恰相反:David主动放弃品牌,要求分叉更名,将项目推向死亡线,以“消失”作为杠杆。
手段强硬,效果立竿见影。这种做法未来定会被效仿。但前提极为苛刻:项目必须足够关键,维护者必须拥有信誉,商业用户必须真正依赖。三者缺一不可。
普通小项目如此操作只会真正死亡。pgBackRest如此操作,市场便会出价。
这是否只是孤例?
PostgreSQL社区的肌肉记忆确实强大。二十余年协作积累,PG圈内人士彼此熟悉,邮件列表、会议、Slack、Twitter/X渠道畅通。事发后可迅速聚首协商,这是PostgreSQL生态的底蕴。
但pgBackRest能复活,因其条件得天独厚:不可替代性强、商业PG服务商深度依赖、David本人愿意继续、多家厂商可协调出资。
若换成其他项目,未必有此结果。
Patroni若出事大概率也有人救,因它是HA领域事实标准,太过关键。
连接池PgBouncer大概也能享受类似待遇。但其他项目呢?PostgREST、pgBadger呢?这些项目同样面临维护压力,却未必具备pgBackRest如此强大的商业救援条件。
其次,临时赞助联盟并非长效治理结构。多家公司出资比单一公司供养维护者更稳定。但资金增加也意味着意见增多。过去David可快速单独做出技术判断;未来背后有五六家金主,路线、优先级、发布节奏都可能变得复杂。
若该联盟一年后仍能稳定发布版本、处理PR、应对安全问题,便构成可复制模式。若首次路线分歧即分崩离析,最终仍需回归基金会托管。
还有更现实的层面:AI时代的预算重排确是事实。
Lætitia那句“他们要买内存、要采购GPU”并非修辞。2025至2026年,CFO面前最易讲通ROI的是GPU、agent、vector、AI-native。备份维护、DBA、可靠性工程属于“坏事未发生”的成本中心,缺乏经验的管理者只有吃过亏才能意识到其价值。
Crunchy Data被Snowflake收购后,原先支撑David维护pgBackRest的资金/岗位路径未能延续。这并非孤例,未来类似事件只会愈发频繁。
用户行动指南
对于pgBackRest用户而言,无需更换,无需折腾。长期使用经验表明——pgBackRest是PG生态中最成熟稳定、功能最丰富的开源备份/恢复工具。不折腾,方为最优策略。
其最大挑战在于配置学习曲线较陡。但一旦配置完成,它将成为数据库武器库中的终极兜底方案。Pigsty已为用户配置好开箱即用的pgBackRest,无需手动折腾。
若正在使用pgBackRest,请继续放心使用。v2.58.0版本无任何问题。此前归档仅意味着长期缺乏维护可能产生影响,如今已恢复维护,自然更加可靠。
写在最后
七日逆转固然值得庆贺,此次事件堪称完美结局。但更应铭记:这次逆转,是因为David Steele不得不将项目推向死亡线,市场才愿意承认其价值。
此事再次印证了那句老话——开源软件并非免费——你使用的开源软件或许无需付费,但维护者同样需要谋生养家。许多人长期认为无需付出成本,搭便车即可,但若人人皆选择白嫖,公地悲剧必然上演。
这句话被David Steele以最硬核的方式验证。不是通过布道、呼吁,或“社区应当如何”的道德说教,而是通过归档项目,将所有依赖方按到同一张账单前。
这不是最佳解决方案,但它有效。衷心希望开源用户能在能力范围内,考虑支持所使用的开源项目。切勿等到维护者走到死亡线时,才开始亡羊补牢。
延伸阅读
- pgBackRest停止维护事件始末
- pgBackRest官网公告
- pgBackRest GitHub README维护更新
- Notice of Obsolescence
- pgBackRest is dead. Now what?
- pgBackRest is archived, what now?
- Open source doesn’t die. It gets unfunded.
- pgxbackup: Continuity Support for pgBackRest
- Supabase Developer Update - April 2026
