Postgres主宰數據庫世界，而誰來吞噬PG？

Percona 是 MySQL 生態的扛旗者與主要三方廠商，最近幾年也在進軍 PostgreSQL 賽道。本文英文原文今天早上發布在 Percona 博客上。

當然 Percona 主要是想給自己打個廣告，但這沒毛病，這個問題也確實是存在的。老馮將這篇文章翻譯點評一下，并與大家聊一聊這個問題。

The growing dominance of PostgreSQL and the emergence of propriety solutions[1]

截至 2025 年，PostgreSQL 在關系型數據庫市場的份額達到 16.85%，是僅次于 MySQL 的第二大開源數據庫。它已成為 Instagram、Reddit、Spotify，甚至 NASA 等大型數據密集型機構的首選數據庫。截至目前，大約 11.9% 年營收超過 2 億美元的公司在生產環境中使用 PostgreSQL。

新趨勢之下，新老數據庫廠商自然都想從中受益。雖然目前市面上專有 PostgreSQL 產品的數量相比五年前的具體增幅難以精確量化，但有幾個跡象表明：無論是知名廠商還是新創企業，基于 PostgreSQL 的專有解決方案都在大幅增加：

1.云提供商的采用：AWS、Google Cloud、Azure 等主要云廠商現在都提供附帶專有特性和集成功能的 PostgreSQL 托管服務，而在五年前這類服務還不多見。2.企業級方案：近年來商業版 PostgreSQL 產品數量顯著增長，多家供應商（包括 EDB）反饋企業對企業級支持、工具和托管服務的需求非常旺盛。3.初創公司的創新：Neon、Supabase、ParadeDB、PostgresML、Tembo 等新創公司紛紛涌現，提供基于 PostgreSQL 打造的創新型專有解決方案。4.微軟 DocumentDB：微軟正推出 DocumentDB——一個建立在 PostgreSQL 之上的開源 NoSQL 數據庫，兼容 MongoDB 協議。

更重要的是，這一趨勢絲毫沒有放緩跡象。PostgreSQL 對當下熱門的多種高級數據類型提供了良好支持——例如用于 AI/ML 工作負載的向量、用于半結構化數據的 JSONB、通過 Timescale 實現的時間序列功能，以及用于地理空間數據的 PostGIS 擴展。 這些能力使 PostgreSQL 成為各組織構建下一代分析、人工智能和大數據解決方案的理想選擇。越來越多的企業不僅將 PostgreSQL 作為主要的運營數據庫（OLTP），還將其作為復雜分析和 AI 系統的基石。

從行業分布來看，PostgreSQL 的用戶幾乎遍及各行各業——信息技術服務、計算機軟件、互聯網、金融服務、市場營銷與廣告、電信、人力資源、醫療健康、 零售和高等教育等行業均在廣泛采用 PostgreSQL（數據來源：Enlyft[2]）。

專有未必是壞事……至少目前如此

截至 2025 年，各類專有的 PostgreSQL 產品致力于在開源核心的基礎上提供更強大的功能、企業級特性和商業支持，使其對關鍵業務工作負載更具吸引力。 對于缺乏內部專業能力來管理和擴展開源 PostgreSQL 的組織來說，采用專有方案可以說是一個合理且無可厚非的選擇。

然而，IT 主管們不應只顧眼前的便利，還要考慮這一趨勢未來的發展方向。越來越多以開源起家的公司正在尋求轉向閉源模式，以進一步實現商業變現。 比如，Redis 最近將其許可協議變更為 Redis Source Available License（RSALv2）和 Server Side Public License（SSPLv1），限制了代碼的使用方式。2023 年，HashiCorp 也采取了類似做法，將其大部分項目從 Mozilla 公共許可證 2.0 改為限制更嚴格的商業源許可證（BSL）。

老馮注：還有剛剛新鮮出爐的《[3]》

MongoDB 能告訴我們 PostgreSQL 將走向何方嗎？

再看看 MongoDB 或許能帶來一些啟示。MongoDB 曾一度被譽為關系型數據庫的開源替代方案，就如同如今的 PostgreSQL 一樣，但其發展軌跡后來卻明顯轉向了專有化。 MongoDB 公司全力投入數據庫即服務（Database-as-a-Service，DBaaS）領域，圍繞其 Atlas 云數據庫服務構建了一個高度封閉的生態系統。 受此影響，社區貢獻和第三方服務都受到了沖擊，而許可模式的變化——例如改用 SSPL 許可證——實際上讓 MongoDB 在許多場景下變成了閉源產品。

MongoDB 轉向更嚴格的許可證模式及廠商主導的云平臺之路，與另一家巨頭 Oracle 的軌跡如出一轍。投資者要求持續的收入增長，導致 MongoDB 采取的策略進一步強化了對客戶的鎖定、提高了授權費用，并迫使企業簽訂代價高昂的長期合同。 曾經作為開源旗手的 MongoDB，如今與其說像開源，不如說更像 Oracle。毫無疑問，轉向閉源模式是 MongoDB 企業用戶采用率下降的關鍵原因之一。

老馮按：

時至今日，有關 MongoDB 的討論大多集中在如何遷移離開這個企業平臺，而非繼續采用它。 最能體現這一趨勢的例子之一，是 Infisical 于 2024 年 12 月發布的一篇博文（Infisical 是一個“一站式平臺，用于安全地管理應用程序密鑰、證書、SSH 密鑰和配置”）， 標題為《從 MongoDB 遷移到 PostgreSQL 的大遷徙[5]》。 文中解釋道，MongoDB 雖然在他們初創時期表現出色，但隨著發展，他們和客戶“遇到了 MongoDB 在功能和易用性方面的局限”。 文章還提到，將數據庫切換到開源的 PostgreSQL 后，數據庫成本降低了 50%。

對于那些采用專有 PostgreSQL 方案的組織來說，這無疑是一個值得警醒的案例。 雖然 PostgreSQL 本身仍然完全開源，也并非由某個單一廠商掌控，但其周邊生態正穩步朝著廠商受控的模式轉變，鎖定效應日益增強。 大型云提供商的 PostgreSQL 托管服務帶有專有的增強功能，將用戶綁定在各自的平臺上。 面向企業的 PostgreSQL 廠商也在推出專有擴展和增值服務，這些舉措雖然提供了便利，卻對數據庫的真正可移植性構成了障礙。那些曾經讓 MongoDB（以及更早的 Oracle）走向封閉的力量，如今也同樣在 PostgreSQL 的生態中發揮作用。

依賴專有 PostgreSQL 的業務風險

對于 IT 決策者而言，PostgreSQL 商業化所帶來的風險遠不止數據庫架構本身 —— 它甚至會影響整個技術版圖。 專有的 PostgreSQL 服務或許能提供一時的便利，但往往是以犧牲長期敏捷性為代價的。當云成本上漲、授權模式演變時，今天的決定明天就可能變成代價高昂的陷阱。

有限的可移植性可能擾亂上云計劃，使多云戰略復雜化，并阻礙災難恢復。 而隨著廠商不斷推出專有附加組件或激進的產品策略（比如 MongoDB 大力推廣 Atlas），誰也無法預料接下來還會出現哪些新的限制。

供應商鎖定

供應商鎖定是 PostgreSQL 商業化引發的首要擔憂之一。許多專有或托管的 PostgreSQL 產品都捆綁了特定供應商的增強功能，使用戶對該供應商產生依賴。 一旦這種依賴根深蒂固，想要遷移就變得既困難又昂貴——此時您將不得不受制于廠商的各種條款，而這些條款可能隨時改變。

這意味著可能會出現意外的許可變更、支持費用上漲，甚至對 CPU 等資源單位的重新定義。 例如，Oracle 長期以來就因隨意調價、強硬的續約策略和不靈活的合同條款而飽受詬病。

投入越深，脫身越難。如果您在基礎架構中深度嵌入了某家供應商的專有 PostgreSQL 方案， 并在其上投入了大量時間和金錢，那么遷移將演變成一項耗時數年、耗資上百萬美元的龐大工程，只為脫離該供應商的束縛。

更值得注意的是，作為最大的專有 PostgreSQL 供應商之一，EDB 甚至發表過一篇博文為供應商鎖定現象辯護，聲稱這“未必是件壞事”。 文中作者以構建和維護內部 PostgreSQL 所需的專門技術為理由，為選擇專有方案進行開脫（這一點我們稍后還會提到）。但試問，這種論調究竟對誰有利？

對市場變化反應遲緩

被鎖定在既有技術上還會帶來更廣泛的影響。受制于過時或小眾技術的企業往往會停滯不前。當您的團隊被束縛在陳舊的系統中時，他們不再學習新技能，趕不上新技術的發展。 長此以往，這將侵蝕公司的技術基礎——您的團隊也會因為缺乏現代技術棧而難以招攬希望從事前沿工作的優秀人才。由此形成的惡性循環將限制創新能力、降低敏捷性，并削弱適應變化的能力。

成本波動難以預測

成本同樣在發生變化。許多專有 PostgreSQL 廠商現在采用基于資源使用量的計費模式，隨著使用規模增長，費用可能會迅速攀升。一開始看似經濟高效的方案，很快就可能演變為沉重的財務負擔。

?例如，Google Cloud 的 AlloyDB for PostgreSQL 按 vCPU 和內存用量計費，價格因區域和配置不同而異。這種模式雖然靈活，但隨著工作負載規模擴大，成本也會大幅攀升。?又如，AWS 的 Aurora PostgreSQL 需要為 I/O 操作付費，如果不加以監控，整體擁有成本可能會顯著膨脹。

再舉一個實際案例：Percona 最近幫助一家從事會員制和變現服務的平臺客戶完成遷移，替他們擺脫了昂貴的 DBaaS 托管數據庫方案。即便將 Percona 的托管和支持費用計算在內，該客戶每月的基礎設施支出仍然削減了 50% 以上。

潛在的安全和合規風險

安全與合規也是一大隱憂。使用專有或全托管的 PostgreSQL 服務會降低組織對底層基礎設施、安全措施和合規配置的可見性。對于高度受監管行業的公司而言，這種對環境失去控制的情況可能帶來嚴重風險。

PostgreSQL 社區生態的侵蝕

最后，如果 PostgreSQL 持續朝商業化方向發展，其活躍的開源社區——這個數十年來創新的引擎——可能會逐漸失去動力。 由廠商主導的開發模式可能意味著社區驅動的改進減少、對開放標準的采用放緩，從而逐步侵蝕 PostgreSQL 長期以來引以為傲的開放性基因。

有何替代方案？

如前所述，專有的 PostgreSQL 產品會限制靈活性、推高長期成本，并背離 PostgreSQL 最初吸引大家的開源原則。 但現實情況是：即便您想避免上述風險，完全依靠內部團隊構建并運維生產級 PostgreSQL 環境也未必可行——這正是 EDB 所強調的觀點。

也許您的團隊沒有足夠的時間、深厚的專業技能或人手來設計高可用架構、在大規模下調優性能、及時跟進每次版本升級，以及在復雜基礎設施中管理合規。但這并不意味著您只能屈從于專有或云托管方案。

Percona for PostgreSQL 為希望規避專有方案風險、又無力完全自建 PostgreSQL 運維的組織指明了一條清晰的前進道路。 Percona 提供的是一個完全開源、具備企業級水準的 PostgreSQL 解決方案——包含完善的高可用、安全、可觀測性和性能優化等工具支持 —— 且沒有任何專有束縛或意外的許可費用。您依然可以自主掌控數據庫運行的地點和方式，并靈活地將其部署在本地、云、混合云或 Kubernetes 環境中。

老馮評論

Percona 拋出了一個非常重要的問題。PostgreSQL 日益主宰數據庫世界，這個已經基本成為業界共識。但什么樣的 PostgreSQL 會成為未來，仍然是一個高度爭議性的問題。 對于這個問題，老馮在《[6]》專欄里曾多次抨擊過云廠商提供的 RDS / 云數據庫服務 —— 《[7]》 / 《[8]》。

Percona 發行版

Percona 算是比較早一批明確提出 “PostgreSQL 發行版”[9] 概念的開源廠商，他們有兩個非常不錯的擴展 ——pg_stat_monitor[10] 與pg_tde[11]，前者提供了 PostgreSQL 中的高級可觀測性指標，后者則提供透明加密的功能。 Percona 也有一個 PMM 監控工具，算是 MySQL 生態做的非常好的監控平臺，最近也做了一些 PostgreSQL 的支持。 當然，因為 pg_tde 所需的補丁一直沒有合入 PG 主干，因此 Percona 不得不自己制作了打補丁的 PostgreSQL 內核包，以配合他們的 pg_tde 透明加密擴展使用

不過作為同行，老馮覺得如果只是把補丁內核，運行高可用/PITR PG 所需的軟件打個包放到 Percona 軟件倉庫里，這個發行版的價值主張確實有些過于單薄，難以支撐起上面提到的 “反擊專有方案” 的使命與大旗。 畢竟這樣的事情，PostgreSQL 全球開發組（PGDG）已經做了，而且做得還相當不錯 —— 至少你得把如何部署，交付整個服務的部分給做了吧，丟給客戶一些 RPM/DEB 包，顯然想跟 RDS 掰手腕是遠遠不夠的。

當然，我跟 Percona 的創始人 Peter Zaitsev 也有過交流，惺惺相惜，肯定算是同道中人。所以他沒做的部分，我可以幫 Percona 補上。 這也是為什么在 Pigsty 3.6 中，我們提供了對 Percona PostgreSQL 發行版的支持

你現在可以用傻瓜式的一行命令，啟用 Percona 帶有 TDE 加密的內核。 并完整的集成了 etcd / haproxy / patroni 高可用， pgbackrest / minio 備份恢復，grafana / prometheus 監控，以及 ansible IAC。 當然，如果你使用原生 PG 內核，還有整整 423 個擴展插件可供選擇，我會在未來考慮為 Percona 這樣的 PG 內核分支也構建這些擴展包。

curl -fsSL https://repo.pigsty.io/get | bash; cd ~/pigsty;
./configure -c pgtde # 使用 percona postgres 內核
./install.yml # 使用 pigsty 設置一切

我認為想要避免 “供應商” 鎖定，正在做到自主可控，實現軟件自由，僅僅開源內核和擴展的代碼是遠遠不夠的，而應該讓用戶能夠在脫離網絡，甚至脫離專家支持的情況下，仍然能夠持續運營下去。 因此，我提供了 Percona 倉庫的鏡像，并且確保用戶在使用 Pigsty 安裝包括 Percona PG 發行版在內的10種 PG 內核時，本地都會有完整的安裝包與系統依賴，自動生成一個 YUM/APT 軟件倉庫， 可以供用戶在斷網環境中，輕松部署復制出一模一樣的環境與節點，實現獨立運營到地老天荒的效果。

甚至，就連構建這些 RPM/DEB 包的完整說明，工具，我也都完全放在 GitHub 上開源了。 而更重要的是，比起給你 RPM/DEB 包，更重要的是如何把這些包攢成企業級服務的經驗，這些經驗沉淀為 Ansible Playbook 與 SOP，以一鍵部署，開箱即用的方式，讓即使是新手也能輕松上手。

Pigsty 元發行版

老馮認為 PostgreSQL 數據庫世界需要有一個代表 “軟件自由” 價值觀的開源發行版，這也是我做 Pigsty 的原因 —— 提供一個功能覆蓋 RDS 的本地優先，開源免費的上位替代。

前幾天， Pigsty 剛剛發布了 v3.6 版本，我在 PG 社區官網新聞上將其稱為一個 “元發行版”，也就是發行版的發行版。

PostgreSQL 社區新聞：Pigsty v3.6， 一個 PG Meta-Distribution

它可以絲滑運行像 “Percona” 發行版，IvorySQL 發行版，PolarDB 發行版，WiltonDB 發行版，OrioleDB，OpenHalo 等各種各樣的 PG 內核發行版，并將其轉換為一套開箱即用的 RDS 服務。 加上 Percona 的 TDE 內核，目前我們已經支持了好幾種種風味的 PG 內核，如果 Citus，TimescaleDB，Omnigres 這樣的巨型擴展，或者把 Supabase，Gel 這類封裝 PG 內核的項目也算做發行版，數量還要更多，已經有十幾種了。

在以前，這種服務你需要在 AWS 或者各家 DBaaS 上花大錢去購買，而且還會被束手束腳，忍受各種功能閹割，以及乞丐云盤帶來的性能羞辱。 而如果想要自建，經驗豐富足的 PostgreSQL DBA 是如此稀缺，即使是 [12]。

自由是最昂貴的頂級奢侈品—— 老馮深知軟件自由的美好，以及它背后的高昂代價。 但老馮希望有更多人有機會享受到它,讓每個人都能輕松負擔的起可靠，穩定，省心的企業級 PostgreSQL 服務，享受 PostgreSQL 生態的樂趣。

這就是 Pigsty 所做的事情 —— 一個開源免費，且真正代表 “軟件自由” 價值觀的開源 PostgreSQL 發行版，讓你脫離供應商，許可證，互聯網，軟件倉庫，甚至是技術專家的 “鎖定”，實現終極意義上的自主可控與軟件自由。

參考閱讀 References

[1]The growing dominance of PostgreSQL and the emergence of propriety solutions:https://experience.percona.com/postgresql/postgresql-market-in-2025/the-growing-dominance-of-postgresql
[2]Enlyft:https://enlyft.com/tech/products/postgresql
[3]KubeSphere 斷供跑路:/cloud/kubesphere-rugpull
[4]《StackOverflow 2025 調研》中，MongoDB 成為年度最大輸家:[so2025-pg](/pg/so2025-pg)
[5]從 MongoDB 遷移到 PostgreSQL 的大遷徙:https://infisical.com/blog/postgresql-migration-technical
[6]云計算泥石流:/cloud/
[7]云數據庫是不是智商稅:/cloud/rds
[8]公有云是不是殺豬盤:/cloud/ebs
[9]“PostgreSQL 發行版”:https://docs.percona.com/postgresql/17/third-party.html
[10]pg_stat_monitor:https://ext.pgsty.com/e/pg_stat_monitor
[11]pg_tde:https://ext.pgsty.com/e/pg_tde
[12]像 OpenAI 這樣的頂級獨角獸也要付出高昂的故障代價自己砸人培養:/db/openai-pg/
[13]PZ：MySQL還有機會趕上PostgreSQL嗎？:/db/can-mysql-catchup
[14]Oracle最終還是殺死了MySQL:/db/oracle-kill-mysql/
[15]Oracle 還能挽救 MySQL 嗎？:/db/can-oracle-save-mysql/
[16]MySQL性能越來越差，Sakila將何去何從？:/db/sakila-where-are-you-going/
[17]PostgreSQL會修改開源許可證嗎？:/pg/pg-license/
[18]草臺班子唱大戲，阿里云PG翻車記:/cloud/rds-failure/
[19]KubeSphere：開源斷供背后的信任危機:/cloud/kubesphere-rugpull/
[20]WordPress社區內戰：論共同體劃界問題:/cloud/wordpress-drama/
[21]MongoDB沒有未來：好營銷救不了爛芒果:/db/bad-mongo/
[22]Redis不開源是“開源”之恥，更是公有云之恥:/db/redis-oss/
[23]范式轉移：從云到本地優先: /cloud/paradigm/

數據庫老司機

點一個關注 ??，精彩不迷路

博客站：https://vonng.com/db

對 PostgreSQL， Pigsty，下云 感興趣的朋友

歡迎加入 PGSQL x Pigsty 交流群（備注加PG群）

（這個小助手很懶，請使勁拍打他）

??????????