PostgreSQL备份神器pgBackRest停止维护：开源可持续性危机与未来出路深度解析
David Steele 亲笔：十三年心血之作正式落幕
2026年4月27日，PostgreSQL生态系统中最重要的备份解决方案pgBackRest被其创始人David Steele正式归档。
相关声明同时在GitHub和LinkedIn平台发布，措辞简洁而决绝：
pgBackRest已停止维护。若您基于此项目创建分支，请为您的项目重新命名。
经过深思熟虑，我决定终止对pgBackRest的后续开发。这绝非草率之举。过去十三年间，pgBackRest始终是我倾注心血的个人项目；在相当长的一段时间里，我幸运地获得了企业赞助支持，但我也付出了无数深夜与周末的时光，与众多贡献者携手将其打造成今日的模样。每位开源开发者都深知这种状态意味着什么，也明白一个被珍视的项目会在生命中占据何等分量。
自Crunchy Data被收购以来，我仍在持续维护pgBackRest，同时也在寻找能让我继续这项事业的职位，但迄今未果。同样，我为项目争取独立赞助的努力，也远未达到支撑其可持续运营所需的水平。
与所有人一样，我需要维持生计。而与pgBackRest相关的职业机会极为稀缺。如今我可以考虑更广泛的就业选择，但这些工作无法留给我足够时间继续投入pgBackRest。项目的日常维护、缺陷修复、PR审查、问题响应等都需要耗费大量精力，更不必说我真正热爱的新功能开发。与其勉强维持、断断续续地低效运作，不如明确画上句号。
我相信pgBackRest终将出现分支版本。但那将是全新维护者主导的新项目，他们必须像我们当年一样，从零开始重建社区信任。
最后，再次感谢多年来所有为pgBackRest贡献力量的开发者。与诸位共事，是我职业生涯的荣幸。
PostgreSQL社区遭遇重大冲击：当事实标准成为孤儿
对PostgreSQL用户群体而言，此事绝非等闲。pgBackRest早已成为PostgreSQL备份恢复领域的事实标准，更是众多DBA心目中最值得信赖的灾难恢复工具。大量PostgreSQL DBaaS服务均将其作为核心备份方案，Pigsty发行版也默认采用该工具。
pgBackRest将PostgreSQL备份技术推向了极致境界：
- 并行化备份与增量恢复，将恢复时间窗口压缩至最小
- 将原本复杂的PITR（基于时间点恢复）操作简化为单条命令
- 完美解决了备份归档、仓库管理、对象存储集成等棘手问题
- 全量、差异、增量备份，块级压缩与加密，多仓库异步归档，从备库执行备份……几乎所有DBA能想象到的备份需求，它都已实现，且表现稳定、品质卓越
笔者十年前首次为生产数据库选型备份方案时便选择了它，近期重新评估市面上所有活跃方案后，结论依然是它。当年2.0版本发布时，我甚至手动翻译了其完整文档。上个月刚借助Claude将相关文档连同Patroni、PgBouncer一起重新翻译了一遍。
这个工具我已稳定使用近十年，对其信赖有加。如今唯一的维护者却将仓库归档了。
资本游戏下的牺牲品：Snowflake收购Crunchy Data始末
David在告别信中说得直白：他未能筹集到足以维系开发的经费。
David此前担任Crunchy Data的架构师，这是一家专业的PostgreSQL服务提供商。2025年6月，数据湖仓领域的巨头Snowflake以2.5亿美元收购了Crunchy Data。
收购完成后，David花费数月时间试图在新东家或其他地方寻找能延续该项目的岗位，但最终失败。他也曾尝试独立筹措赞助资金，但距离维持生计的目标差距甚远。他需要养家糊口，因此选择果断终止，而非敷衍了事。
这里存在一个令人不安的事实：Snowflake是当前数据基础设施领域市值最高的企业之一，公开宣称要打造"AI原生Postgres"，斥资2.5亿美元收购Crunchy。但从结果看，却未继续支持David维护pgBackRest。一家小公司尚能承担的开发者成本，进入大公司后反而无法覆盖。
若此推测属实，其行为的短视程度远超商业理性的范畴。Snowflake节省的成本微不足道，却亲手抽掉了PostgreSQL生态最关键的承重支柱之一，这并非精明的商业决策，而是吃相过于难看。
本轮AI淘金热潮已彻底重塑企业预算清单。采购内存、GPU、tokens等投入能讲出清晰的ROI故事；而雇佣一名确保数据库崩溃后可恢复的专家，却无法量化回报——“坏事未发生"在董事会面前等于零价值。
社区大讨论：开源项目生死劫的三重困境
事件发酵数日以来，PG社区已沸腾：Hacker News上超过200分的讨论串、各大厂商博客的连续回应、邮件列表中"接下来怎么办"的激烈辩论。讨论主要围绕三个层面展开。
第一层：开源可持续性诊断。主流观点认为健康模式应形成良性循环：“企业投资工程师→软件创造价值→用户购买商业支持→企业再投资”。pgBackRest的困境在于该闭环未能建立——仅依赖单一公司工程师维护，未形成多厂商商业支持网络。一旦该公司被并购或战略调整，整条链路即时断裂。
**第二层：是否立即分叉。**大厂态度高度一致：暂缓分叉。 “不应出现十个分叉、每个仅一人维护"的碎片化局面才是最差结果。Linux Foundation推出Valkey替代Redis耗时六天紧急协调，多厂商共治事宜，慢而稳优于快而乱。
**第三层：分叉命名问题。**David在声明中明确表态：“我希望它被分叉，但那将是新项目、新维护者，需如我们当初般重建信任。“这意味着新项目不得继续使用pgBackRest名称。
笔者个人支持David的要求，这恰是他离场时最负责任的举措。备份工具是供应链攻击的最高价值目标之一：一个被广泛信任的备份程序若在升级中被植入恶意代码，可获取几乎所有部署实例的核心权限，接触全部历史数据。将"数千星标积累的信任"直接转让给未知继任者不是慷慨，而是不负责任。强制分叉改名，是促使用户重新进行信任评估，此乃安全工程的基本准则。
亲历者视角：pgBackRest的未来何去何从
笔者得知此消息时深感遗憾。
作为pgBackRest的深度用户，若无人接手，我本人也愿意扛起维护重任。
此前我已接手MinIO的维护，因自身需求在原厂放弃后fork维护至今。我认为在不新增功能的前提下，接手pgBackRest维护并非不可行。
不过，我认为pgBackRest未必会走到那一步，其未来存在几种可能路径。
可以确定的是，5月温哥华PGConf.Dev大会极可能将此作为核心议题讨论。涉及PG生态主要厂商核心利益的工具，社区不会坐视不管。
现实预期是，社区协商产生新分叉，类似Redis改协议后社区另立Valkey。鉴于不可沿用原名，新项目可能命名为pgbackrest-ng、pgbacknext或其他。此方向的关键在于需要一家或多家厂商作出长期承诺并达成共识。
较坏情况是，既无牵头者，也未进PGDG，厂商间未达共识，陷入"各维护内部fork"状态：Percona一份、EDB一份、各云厂商一份。此结局最糟糕，真正的"Fork战争”。
最理想结果是PGDG内核团队接手，作为contrib模块或纳入PGDG全球开发组项目集。但实话实说难度较大，且其他备份工具维护者未必乐见。
当前现状是，Percona已明确表态将继续为自家客户提供pgBackRest支持。这意味着至少在企业客户层面，pgBackRest不会立即失去所有支撑。Crunchy现有产品与文档仍深度集成pgBackRest，但截至目前未见其对项目长期维护作出新的公开承诺。
笔者也在此明确表态：若无他人维护，我将自己接手。当然若他人维护得当，我也乐见其成为上游，专注验证、打包分发及用户反馈。
用户行动指南：冷静评估而非恐慌性迁移
短期来看，我给诸位PostgreSQL DBA的建议是：若您正在使用pgBackRest，无需过度担忧。切勿恐慌，更无需急于迁移。
pgBackRest是极其成熟的软件，归档的是代码仓库——不再接受PR、不再修复bug、不再发布新版本，但代码本身依然存在，今天运行良好的系统，明天仍可继续运行。
当前使用pgBackRest会有什么问题？ 如果您一直使用PostgreSQL 18配合pgBackRest v2.58，这套组合可运行至天荒地老。
风险的出现需要时间，可能是数月乃至数年后。例如今年9月PG19发布，或后续大版本引入需适配的内核改动，抑或对象存储、依赖库、安全漏洞需要后续修复时，问题才会显现。pgBackRest当前版本兼容PG18，但新大版本若需内核层适配，或出现必须修复的安全问题，情况将变得棘手。然而这是中长期担忧，而非当下危机。
更重要的是，目前没有任何工具能完全平替pgBackRest的功能完备度：
- Barman（EDB维护）是最可靠备选之一，3.18版本新增云存储块级增量备份能力，但该特性较新，成熟度与一体化体验距pgBackRest尚有差距
- WAL-G是实用的云归档与恢复工具，在K8s/云原生场景应用广泛，但在完整备份仓库治理能力上与pgBackRest并非完全重叠
- pg_probackup（Postgres Professional出品）曾是唯一能在功能维度与pgBackRest抗衡的对手，其块级PTRACK增量备份甚至更激进。但作者公司为俄罗斯背景，2022年后处境复杂；更关键的是该工具历史上曾出现恢复后数据丢失、无效页面等严重问题（如#474[1]、#249[2]）。对备份工具而言，这是致命污点，令我个人在推荐时极为慎重
因此，最佳策略是保持现状，避免折腾——频繁变更反而是最大风险。继续使用v2.58作为未来一段时间的稳定基线，同时扎实演练恢复流程，关注PGConf.Dev后社区是否出现明确接班分支，再作下一步决策。
开源世界的阿喀琉斯之踵：价值创造与捕获的永恒悖论
David的故事最值得反思之处在于：他并非业余爱好者燃尽退场的典型，而是在Crunchy Data领取薪酬从事开源工作——这正是开源社区反复倡导的"健康模式”。然而该模式被Snowflake的并购轻易摧毁。
2025年以来，PostgreSQL领域资本动作密集：Databricks宣布收购Neon（传闻约10亿美元）、Snowflake收购Crunchy Data（约2.5亿美元）、Databricks随后又收购Mooncake Labs、Supabase据传正以约100亿美元估值洽谈融资。
这把双刃剑一方面为数据库这个相对"不性感"的领域引入更多资本，另一方面这些原本小而美、运作良好的公司被资本裹挟后，便出现了今日这般荒诞现象。原本健康运转的开源赞助闭环，因一次并购即被切断。
笔者在运作自身项目时也有云厂商洽谈收购，但我总会反复权衡一个问题：**若被收购，开源事业还能否继续？**这是每一位有情怀的创始人必须自问的命题。
对绝大多数普通开发者而言，“工具好不好用"才是硬道理，谁会关心维护者的薪资单？但对企业而言，态度应截然不同。
当前现状极为魔幻：大量Postgres公司、DBaaS厂商、托管服务都在使用pgBackRest，几乎成为事实标配。但查看pgBackRest项目页的赞助商列表，目前仅列出Supabase一家。财力雄厚的云厂商比比皆是，却心安理得地免费享用，这正是公地悲剧的精准写照：当所有人都默认"会有别人买单"时，该模式便彻底崩溃。
背后更深层的原因在于开源世界的根本矛盾：价值创造与价值捕获的分离——创造软件的人与利用软件获利的人并非同一群体。AWS等云厂商每年从托管Postgres及相关服务中获利数亿乃至数十亿美元，但Postgres核心团队分不到分文。同样的剧本曾在Redis、Elasticsearch、MongoDB反复上演，剧情大同小异。
在PG生态中，类似pgBackRest这种非内核但实质支撑整个生态的支柱性项目还有很多：
- Patroni：PG高可用的事实标准之一，大量自建集群及部分K8s Operator背后都是它
- PgBouncer：PG连接池的事实标准，在中大规模Postgres部署中极为常见
- 加上各类FDW、contrib扩展、监控组件……
PG世界"并不缺"备份、连接池、高可用工具，每个领域都有多个选择。但若追求"最佳"方案，选项往往唯一。若这些项目得不到良好维护与反馈循环，将是PostgreSQL生态真正的风险所在。
个人项目的生存启示录：Pigsty的得与失
David的故事令我感触颇深，也给予我诸多启示。
我创立的PG发行版Pigsty，作为开源PostgreSQL发行版已算得上相当成功。从GitHub星标数、社区口碑到企业部署规模来看，在Linux原生发行版这一细分赛道，我认为Pigsty已跻身顶尖行列。
但它同样由我个人独立维护——从编码、发版、写文档到答疑、撰文、录教程。我能坚持至今，本质上依赖两个前提同时成立：
- 我真心热爱此事。数据库、Postgres、运维自动化、开源是我离开大厂后持续投入的领域，乐在其中，愿意继续
- 更重要的是，确实有企业客户为此付费，跑通了商业循环
我能吃饱饭、无生计之忧，又能做热爱之事，在精神与物质层面获得双重满足，因此能够持续维护。但若任一前提不再成立，Pigsty可能就是下一个pgBackRest。
因此David事件对我而言远非行业新闻，而是关于项目如何交接、如何可持续生长的活生生案例。商业客户付费意味着明确的责任与承诺约束；开源一面则本质依赖善意（Goodwill），而善意会被白嫖与恶言消耗，会被并购与裁员吞噬。
若未来我实现财务自由，我也乐意出资赞助Postgres上游项目及生态支柱：pgBackRest接班人、Patroni、PgBouncer……这是基本责任感。
今日这些工具尚能使用，是因为有人在替你负重前行。他们扛不住了，你的系统也会崩塌。
最后，回到David Steele。
我们这些受益于pgBackRest十余载的用户，欠他一句郑重的：
谢谢。
希望他早日找到合适的归宿。也但愿他打造的这件作品，能以新形态继续陪伴PostgreSQL走过下一个十年。
参考资料
[1] #474: https://github.com/postgrespro/pg_probackup/issues/474
[2] #249: https://github.com/postgrespro/pg_probackup/issues/249