pgBackRest生死七日逆转：开源维护者如何用“消失”倒逼市场定价

May 9, 2026

几天前，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以最硬核的方式验证。不是通过布道、呼吁，或“社区应当如何”的道德说教，而是通过归档项目，将所有依赖方按到同一张账单前。

这不是最佳解决方案，但它有效。衷心希望开源用户能在能力范围内，考虑支持所使用的开源项目。切勿等到维护者走到死亡线时，才开始亡羊补牢。