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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

老馮按：

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

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

依賴專有 PostgreSQL 的業(yè)務風險

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

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

供應商鎖定

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

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

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

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

對市場變化反應遲緩

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

成本波動難以預測

成本同樣在發(fā)生變化。許多專有 PostgreSQL 廠商現(xiàn)在采用基于資源使用量的計費模式，隨著使用規(guī)模增長，費用可能會迅速攀升。一開始看似經(jīng)濟高效的方案，很快就可能演變?yōu)槌林氐呢攧肇摀?/p>

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

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

潛在的安全和合規(guī)風險

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

PostgreSQL 社區(qū)生態(tài)的侵蝕

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

有何替代方案？

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

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

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

老馮評論

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

Percona 發(fā)行版

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

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

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

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

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

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

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

Pigsty 元發(fā)行版

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

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

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

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

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

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

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

參考閱讀 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 調(diào)研》中，MongoDB 成為年度最大輸家:[so2025-pg](/pg/so2025-pg)
[5]從 MongoDB 遷移到 PostgreSQL 的大遷徙:https://infisical.com/blog/postgresql-migration-technical
[6]云計算泥石流:/cloud/
[7]云數(shù)據(jù)庫是不是智商稅:/cloud/rds
[8]公有云是不是殺豬盤:/cloud/ebs
[9]“PostgreSQL 發(fā)行版”: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 這樣的頂級獨角獸也要付出高昂的故障代價自己砸人培養(yǎng):/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社區(qū)內(nèi)戰(zhàn)：論共同體劃界問題:/cloud/wordpress-drama/
[21]MongoDB沒有未來：好營銷救不了爛芒果:/db/bad-mongo/
[22]Redis不開源是“開源”之恥，更是公有云之恥:/db/redis-oss/
[23]范式轉(zhuǎn)移：從云到本地優(yōu)先: /cloud/paradigm/

數(shù)據(jù)庫老司機

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

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

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

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

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

??????????