pgBackRest 續命戰與開源世界的逼定價

幾天前，PG 生態的頂級開源備份工具 。

老馮的 Pigsty 雖然也用著 pgBackRest，但也不著急，因為我知道這么重要的組件 pgBackRest，PostgreSQL 生態不可能真讓它死掉。 但也承諾如果過一段時間都沒人接盤，我會來接手維護?，F在看來，倒是不需要了。

David Steele 在 GitHub README[2] 上發了一份“維護更新”：歸檔公告發出之后，他的郵箱被打爆了。 很多用戶和廠商都希望項目繼續；他自己也愿意繼續；更關鍵的是，多個贊助商組成的聯盟已經基本談攏，他幾乎可以確定拿到足夠資金繼續維護 pgBackRest。

他預計在本周結束前給出更明確公告。從歸檔到反轉，七天。

這事有意思的地方不在于 “開源社區真有愛”。這種話太輕飄了。真正有意思的是：一個關鍵開源基礎設施被維護者按到死亡線之后，市場終于開始出價了。

這是一次非常干凈的開源公地逼定價。

七天里發生了什么

先把時間線捋清楚。

4 月 27 日，David Steele 在 GitHub 和 LinkedIn 同時宣布停止維護 pgBackRest，倉庫歸檔[3]。聲明很克制，沒有抱怨，也沒有甩鍋，只說了兩件事：

?fork 可以，但不要繼續叫 pgBackRest。?歸檔不是 EOL，代碼還在，正在跑的部署不會突然壞掉。

第一條其實很重要。備份工具不是普通小玩具，而是供應鏈攻擊的高價值入口。一個帶著原品牌信任的 fork，如果落到不靠譜的人手里，風險比大家想象的大得多。David 要求改名，是他離場時最負責任的一步。

同一天，Christophe Pettus 在 thebuild.com 發了《Notice of Obsolescence》[4]。他的判斷比較冷：pgBackRest 應該按“落日部署”處理，等可信 fork 出來再重新評估。

同日，L?titia Avrot 發了《pgBackRest is dead. Now what?》[5]。標題就很直白。她把話說得更狠：AI 淘金熱已經重排了企業預算。大公司愿意買內存、買 GPU、買 token，但不愿意付錢給那個保證數據庫炸了還能恢復回來的人。

這話難聽，但真實。

4 月 28 日，Percona 出手了。Jan Wieremjewicz 發了《pgBackRest is archived, what now?》[6]，說 Percona 會繼續支持 pgBackRest，但大家不要急著 fork。他們正在和其他廠商討論多廠商聯合維護，或者基金會托管。 這篇里還有個關鍵信息：Jan 說，他在歸檔前一周的 PGConf.DE 演講中還引用過 David 提出的透明出資模型，希望把維護成本分攤給多家依賴 pgBackRest 的組織。

這一步是關鍵。Percona 沒有宣布自己接盤，也沒有搶著做 fork，而是先呼吁協調。對于一個商業供應商來說，這種克制不多見。

但沒人及時接。

也就是說，David 不是沒有試過“和平定價”。只是和平定價沒人買賬，最后只能歸檔。

4 月 30 日，Percona 又補了一篇《Open source doesn't die. It gets unfunded.》[7]，把問題說得更直白：pgBackRest 不是 EOL，而是維護資金斷檔；Percona 和其他公司正在幕后推動解決方案。

5 月 1 日，PGX 搶跑。Christophe Pettus 旗下的 PGX Inc. 發了《pgxbackup: Continuity Support for pgBackRest》[8]，把 pgBackRest fork 成了 pgxbackup[9]，定位是給自家支持客戶用的 continuity release，只做關鍵 bug 修復和新 PG 版本兼容。

這一步合理，但也微妙。Percona 才說“先別急著 fork”，PGX 三天后就 fork 了。你不能說 Pettus 不負責，他當然要對客戶負責；但這也說明，所謂“社區協調”其實很脆。只要有一家廠商等不及，雙軌預期馬上形成。

5 月 4 日左右，David 發出維護更新：贊助聯盟基本成形，資金大概率夠了。他還在找另一位維護者分擔工作量，避免項目繼續變成單點。

至此，逆轉完成。

Linux 基金會當年響應 Redis 改協議、發起 Valkey[10]，按自然日約八天，按工作日約六天。pgBackRest 這次沒有基金會、沒有牌照戰爭、沒有共同敵人，純靠 PG 圈內部協調，用了七天。

這個速度已經很快了。

誰可能掏錢：公開信號與猜測

正式名單還沒出來，但公開信號已經夠畫個大概。

Supabase 是目前公開信號最強的候選金主。

按 pgBackRest 官網和 README 的 sponsor 口徑，目前列出的 current sponsor 是 Supabase。更關鍵的是，Supabase 4 月在 Developer Update - April 2026[11] 里說，剛開源 Multigres[12] Kubernetes operator，里面直接內置 pgBackRest PITR 備份。

這就不是“支持一下開源”的關系了，而是產品路線綁定。你把未來押在一個備份工具上，這個工具突然沒維護者了，你不出錢誰出錢？

以 Supabase 現在的估值和融資規模，養一個 pgBackRest 核心維護者根本不是錢的問題，而是認不認賬的問題。至于它是不是 coalition 里的最大出資方，還要等正式名單。

Percona 大概率是協調者之一。Percona 已經公開承諾會繼續支持 pgBackRest，而且 Percona Distribution for PostgreSQL 也長期把 pgBackRest 作為推薦備份工具。他們的客戶 SLA 掛在這上面，不可能只在旁邊看熱鬧。 但它是否出資、出多少，要等正式公告。它目前更像這次協調里的組織者之一。

Cybertec、Timescale、Resonate 都有可能參與。Cybertec 的容器化 PG 產品里用到了 pgBackRest；L?titia 文章里也專門點名 Cybertec 和 Data Egret 有專家可以臨時處理 pgBackRest 問題。 Timescale 有公開 fork[13]，這是一個依賴或評估信號，但不足以單獨證明 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[14] 或 WAL-G[15]，要重做備份恢復流程，還要重新演練災備。?自己內部 fork，要養懂 PG、懂備份、懂 C 和 Perl 的高級工程師。?幾家公司聯合出錢，讓 David 繼續維護主線。

第三個方案最便宜。

這就是逼定價。它不是傳統意義上的勒索。代碼是 MIT 協議，誰都可以 fork，誰都可以繼續用。David 沒有把代碼鎖起來，也沒有改協議收稅。他能撤回的，只有自己的時間和信譽。

但在開源基礎設施里，維護者的時間和信譽恰恰是最貴的部分。

Redis／Valkey[16]、HashiCorp Terraform／OpenTofu[17]、Elastic／OpenSearch[18] 那幾次， 是用商標和協議做杠桿，結果社區被迫 fork，自己也傷筋動骨。pgBackRest 這次相反：David 主動放棄招牌，讓 fork 改名，把項目推到死亡線，用“消失”做杠桿。

很硬，也很有效。我猜這招以后一定會有人學。前提也很苛刻：項目必須足夠關鍵，維護者必須有信譽，商業用戶必須真依賴。三者缺一不可。

一般小項目這么干，只會真死。pgBackRest 這么干，市場會出價。

這是一個特例嗎？

PG 社區的肌肉記憶確實強。二十多年協作下來，PG 圈的人互相認識，郵件列表、會議、Slack、Twitter／X 都通著。出事之后，大家能很快坐到一張桌子上。這是 PostgreSQL 生態的底子。

但 pgBackRest 能復活，是因為它條件太好了：不可替代性強，商業 PG 服務商依賴深，David 本人愿意繼續，還有多家廠商能協調出錢。

換成別的項目，就未必。

Patroni[19] 如果哪天出事，大概也有人救，因為它算是 HA 領域的事實標準，太關鍵。

連接池 PgBouncer[20] 大概也會有這個待遇、那其他項目呢？PostgREST[21]、pgBadger[22] 呢？ 這些項目背后都有各自的維護壓力，但未必都有 pgBackRest 這么強的商業救援條件。

其次，臨時贊助聯盟不是長期治理結構。多家公司出錢，比單一公司養維護者穩。 但錢一多，意見也會多。過去 David 一個人做技術判斷很快；以后背后有五六家金主，路線、優先級、release cadence 都可能變復雜。

如果這個聯盟一年后還能穩定發版本、接 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[23] 沒毛病 之前歸檔也只是說未來時間長了，缺少維護才可能會有影響，現在繼續維護了，當然就更沒毛病了。

最后

七日逆轉當然值得高興。這次事件算是一次 Happy Ending。但更應該記住的是：這次逆轉，是因為 David Steele 不得不把項目按到死亡線，市場才愿意承認價格。

這件事也再次 echo 了那句老話 ——開源不是免費的—— 你用的開源軟件也許是免費的，但維護它的人也是需要謀生吃飯的。 只是很多人一直認為自己不用付出成本，搭便車就好，可如果大家都選擇白嫖，就會出現公地悲劇。

這句話被 David Steele 用最硬的方式驗證了。不是靠布道，不是靠呼吁，也不是靠“社區應該如何如何”的道德文章。而是把項目歸檔，把所有依賴方按到同一張賬單前面。

這不是最好的解決辦法，但它有效。老馮衷心希望開源用戶能在力所能及的范圍內，考慮支持一下自己使用的開源項目。而不要等到維護者到死亡線了，才開始亡羊補牢。

?pgBackRest 停止維護了[24]?pgBackRest 官網公告[25]?pgBackRest GitHub README 維護更新[26]?Notice of Obsolescence[27]?pgBackRest is dead. Now what?[28]?pgBackRest is archived, what now?[29]?Open source doesn't die. It gets unfunded.[30]?pgxbackup: Continuity Support for pgBackRest[31]?Supabase Developer Update - April 2026[32]

References

[1]pgBackRest 宣告停止維護:/pg/pgbackrest-archive/
[2]GitHub README:https://github.com/pgbackrest/pgbackrest
[3]倉庫歸檔:https://github.com/pgbackrest/pgbackrest
[4]《Notice of Obsolescence》:https://thebuild.com/blog/2026/04/27/notice-of-obsolescence/
[5]《pgBackRest is dead. Now what?》:https://mydbanotebook.org/posts/pgbackrest-is-dead.-now-what/
[6]《pgBackRest is archived, what now?》:https://percona.community/blog/2026/04/28/pgbackrest-is-archived-what-now/
[7]《Open source doesn't die. It gets unfunded.》:https://percona.community/blog/2026/04/30/open-source-doesnt-die-it-gets-unfunded/
[8]《pgxbackup: Continuity Support for pgBackRest》:https://thebuild.com/blog/2026/05/01/pgxbackup-continuity-support-for-pgbackrest/
[9]pgxbackup:https://github.com/pgexperts/pgxbackup
[10]Valkey:https://github.com/valkey-io/valkey
[11]Developer Update - April 2026:https://github.com/orgs/supabase/discussions/44713
[12]Multigres:https://github.com/multigres/multigres
[13]公開 fork:https://github.com/timescale/pgbackrest-public
[14]Barman:https://github.com/EnterpriseDB/barman
[15]WAL-G:https://github.com/wal-g/wal-g
[16]Redis／Valkey:https://github.com/valkey-io/valkey
[17]HashiCorp Terraform／OpenTofu:https://github.com/opentofu/opentofu
[18]Elastic／OpenSearch:https://github.com/opensearch-project/OpenSearch
[19]Patroni:https://github.com/patroni/patroni
[20]PgBouncer:https://github.com/pgbouncer/pgbouncer
[21]PostgREST:https://github.com/PostgREST/postgrest
[22]pgBadger:https://github.com/darold/pgbadger
[23]v2.58.0:https://github.com/pgbackrest/pgbackrest/releases/tag/release/2.58.0
[24]pgBackRest 停止維護了:/pg/pgbackrest-archive/
[25]pgBackRest 官網公告:https://pgbackrest.org/
[26]pgBackRest GitHub README 維護更新:https://github.com/pgbackrest/pgbackrest
[27]Notice of Obsolescence:https://thebuild.com/blog/2026/04/27/notice-of-obsolescence/
[28]pgBackRest is dead. Now what?:https://mydbanotebook.org/posts/pgbackrest-is-dead.-now-what/
[29]pgBackRest is archived, what now?:https://percona.community/blog/2026/04/28/pgbackrest-is-archived-what-now/
[30]Open source doesn't die. It gets unfunded.:https://percona.community/blog/2026/04/30/open-source-doesnt-die-it-gets-unfunded/
[31]pgxbackup: Continuity Support for pgBackRest:https://thebuild.com/blog/2026/05/01/pgxbackup-continuity-support-for-pgbackrest/
[32]Supabase Developer Update - April 2026: https://github.com/orgs/supabase/discussions/44713