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