Pigsty v4.2：12 款PG內核任君選擇

Pigsty v4.2 正式發布，

本次更新同時交付了三款全新 PG 內核 —— 圖數據庫 AgensGraph、多寫分布式 pgEdge、MPP 數倉 Cloudberry —— 并重建了 Babelfish、OrioleDB、OpenHalo 三款既有內核。至此，Pigsty 支持的內核總數達到了 12 個。

你可以用一份配置文件，把所有這些不同風味的 PostgreSQL 部署為自帶監控、高可用、時間點恢復與 IaC 的企業級數據庫服務。這就是 "Meta PG 發行版" 的含義。

內核大觀園

PostgreSQL 以極致的可擴展性聞名。生態中有超過 1000 個擴展，Pigsty 則提供了其中 461 個開箱即用。

但有些能力是擴展做不到的 —— 比如定制語法。如果你想在 PostgreSQL 里原生使用 Oracle 的 PL/SQL、SQL Server 的 T-SQL、MongoDB 的 BSON 協議、或者 Cypher 圖查詢語法，而不是通過函數調用來模擬，那你就需要修改內核。這也是為什么 Pigsty 不僅提供生態中數量最多的擴展，還要支持不同的內核分支。

在 Pigsty 里使用這些內核，和使用原版 PostgreSQL 幾乎沒有區別 —— 同樣的部署流程、同樣的監控面板、同樣的高可用機制、同樣的備份恢復。區別只是配置文件里改一個 pg_mode 的值。一行配置的差異，工程上的大一統。

十二內核，一份配置。下面逐個展開。

原生 PostgreSQL

這次 PostgreSQL 的小版本更新值得單獨提一下。

18.2 系列引入了 substring 與 WAL 回放相關的回歸問題 —— 修漏洞的時候帶進了新 bug。社區反應很快，兩周后緊急發布了 18.3 / 17.9 / 16.13 / 15.17 / 14.22 補丁版本。Pigsty 的做法還是老規矩 —— 新版本發布次日，離線安裝包就緒、所有擴展重新編譯驗證、文檔同步更新。你要做的就是一行命令的事。

擴展總數也順勢推到了 461 個。

如果你追求極致的可擴展性和最佳的穩定性，原生 PostgreSQL 始終是最佳默認選擇。Pigsty 支持處于生命周期內的 PG 14 到 PG 18。值得一提的是，本版本是最后一個支持 PG 13 的版本，后續最低版本將升至 PG 14。

pgEdge：原生多主復制

pgEdge 是本次新增的重量級選手。

傳統 PostgreSQL 高可用是一主多從 —— 寫操作只能發往主節點。pgEdge 的核心擴展 Spock 打破了這個限制：集群中的每個節點都可以讀寫，數據通過邏輯復制在節點間異步同步，沖突通過可配置策略自動解決。

嚴格來說，pgEdge 不是一個全新的內核，而是基于標準 PostgreSQL + Spock 擴展的多主方案。但由于多主復制的一些底層能力需要內核補丁（這些 Patch 尚未合并到 PostgreSQL 主干），它目前不得不以"Patch 內核 + 擴展"的方式發布。這一點和 OrioleDB、Percona TDE 類似 —— 如果 PostgreSQL 主干未來合并了這些 Patch，它們都可以轉變為純擴展形態工作，這是非常值得期待的趨勢。

我很看好這個項目。pgEdge 團隊有幾位 PostgreSQL 社區的內核老將，技術功底很扎實。關于它的開源歷程也值得一說：之前它使用的是類似 Confluent 風格的 Source Available 協議（pgEdge Community License），嚴格來說不算開源。但 2025 年 9 月，它全面轉向了 PostgreSQL License。

不過有個細節需要注意：源代碼遵循 PostgreSQL 協議，但官方提供的二進制包依然受商業許可約束。具體來說，開發環境可以免費使用，但生產環境必須付費訂閱。

老馮直接基于 PostgreSQL 協議的源碼自行打包 —— 制作了帶 Patch 的 PostgreSQL 內核包，并在 Pigsty 支持的全部主流操作系統上完成適配。沒有外部依賴，從 Pigsty 倉庫直接裝就行，不存在生產環境的許可問題。當然，如果你想用他們的云服務和商業支持，也歡迎去打錢支持一下。

pgEdge 由三個核心擴展組成：

?Spock 5.0.5：多主邏輯復制引擎，每個節點同時處理讀寫?Lolor 1.2.2：大對象邏輯復制?Snowflake 2.4：分布式序列號生成

沖突解決方面，pgEdge 提供了多種策略：最簡單的"最后寫入獲勝"（LWW）、專門的 CRDT 方案、沖突日志表、以及用戶自定義策略。如果你有全球地理分布的需求 —— 比如北京、法蘭克福、弗吉尼亞各放一個節點，用戶就近讀寫 —— 這種多主模式非常合適。它相當于在 PostgreSQL 生態里原生提供了類似 CockroachDB / TiDB 的多寫能力，只不過底座還是那個你熟悉的 PostgreSQL。

在 Pigsty 中使用只需要：configure -c pgedge。

AgensGraph：圖數據庫

AgensGraph 的定位是基于 PostgreSQL 的多模型圖數據庫 —— 在一個引擎內同時原生支持關系模型和屬性圖模型，而不是像 Neo4j 那樣另起爐灶。這是由韓國 Bitnine 團隊發起主導的項目。

有人會問：PostgreSQL 生態里不是有 Apache AGE 這個圖擴展嗎？為什么還要做 fork 內核？

這里有個有意思的淵源：AGE 和 AgensGraph 其實是同一個團隊做的。最初他們做的是 AgensGraph 這個內核 fork，大概 1000 多個 Star。后來他們嘗試以擴展形式實現類似功能，做了 AGE 并捐獻給 Apache。結果擴展形式反而更受歡迎，拿到了 4000 多個 Star。AGE 雖然去年經歷了一陣維護風波，但最近已恢復更新，發布了針對 PG 17/18 的 1.7.0 版本。

那 fork 版本還有什么存在價值？至少四個方面：

一是原生語法。在 AGE 里，你需要用函數調用來執行 Cypher 查詢（把查詢字符串傳進去）；而在 AgensGraph 里，你可以直接寫 CREATE GRAPH，Cypher 是一等公民語法。

二是存儲優化。它的存儲引擎針對圖屬性做了專門優化，理論上性能更好（雖然我還沒實際 bench 過）。

三是查詢優化統一。Cypher、JSON、SQL 三種查詢語言在優化器層面是統一處理的，這種原生實現方式很有意思。

四是向量兼容。AgensGraph 最近宣稱支持了 pgvector 兼容，意味著可以在同一個庫里做 Graph RAG —— 圖 + 向量的組合檢索。這是當下非常火的前沿方向。這個專門的 vector 插件我還沒打包進來，后面可能會補上。

當然，fork 路徑的代價也很明顯：版本跟進 PG 主線的難度很高。目前 PG 已經到 18 了，AgensGraph 還是基于 PG 16。這始終是 fork 方案的宿命，要落后一兩個大版本。

在 Pigsty 中使用：configure -c agens。

Cloudberry：MPP 數倉

Cloudberry 是本次新增的第三款內核。它是一個 Apache 項目，由 HashData 團隊主導，本質上是 Greenplum 7 的 fork —— 但做了不少改進，比如內核從 Greenplum 的 PG 12 升級到了 PG 14，補上了不少好用的新特性。

Cloudberry 2.0 發布后就不再提供官方二進制包了 —— 之前 1.18 和 1.19 還有 RPM，現在也沒了。我等了幾個月沒見到官方有計劃解決這個問題，就決定在 Claude 的幫助下自己動手。打包過程整體順利，只是在個別較新的操作系統上需要改些代碼、打幾個補丁。之前只有 RPM，現在 DEB 也有了，Pigsty 支持的 14 個 Linux 發行版上全部可用。

關于 Cloudberry/Greenplum 的部署腳本和監控方案，其實早在 Pigsty v1.4 就做過，后來因為用戶太少就去掉了。畢竟上 MPP 數倉的體量不是一般公司能達到的。所以我們思忖再三，先將其作為 Beta 模塊按需提供 —— 包已經打好放在倉庫里了，你可以直接下載使用；完整的部署劇本會在后續版本中擇機提供。

Babelfish：SQL Server 兼容

說完三個新增內核，再來聊三個重建的內核。

Babelfish 是 AWS 開源的 SQL Server 兼容層 —— 讓 PostgreSQL 理解 T-SQL 語法和 TDS 協議，你的 SQL Server 應用不改驅動、不改大部分查詢，就能連上 PostgreSQL 跑起來。好項目，但打包構建實在是復雜，復雜到專門有一個開源項目 WiltonDB 就是干這件事的。

老馮之前偷懶，直接用了 WiltonDB 打的包。說實話，那個包的質量一直讓我不太舒服：不支持 Debian 全系列和 EL10，依賴體系跟標準 PG 不一樣，而且版本還停留在 PG15 —— 但 Babelfish 上游都已經支持 PG17 了。

這次一不做二不休，自己打。有了前面幾個內核的打包經驗，這個反而簡單了 —— 把 Babelfish 的四個核心擴展打成一個包，配合一個 Patch 內核包，開箱即用。現在不再依賴外部 WiltonDB 倉庫，直接從 Pigsty 倉庫安裝即可。版本升級到了 Babelfish 5.5 + PG17。

在 Pigsty 中使用：configure -c mssql。

OrioleDB：新存儲引擎

OrioleDB 是被 Supabase 收購的新一代 PostgreSQL 存儲引擎項目，目標是從根本上解決 MVCC 膨脹問題 —— 用 Undo Log 替代傳統的 Dead Tuple + VACUUM 機制。

本次重建升級到了 OrioleDB Beta14，基于 OriolePG 17.16 構建。新版本的一個重要進展是支持了 PITR 增量備份恢復能力。仍處于 Beta 階段，不建議關鍵生產環境使用。但作為 PostgreSQL 存儲引擎的未來演進方向之一，值得持續關注和實驗。

在 Pigsty 中使用：configure -c oriole。

OpenHalo：MySQL 協議兼容

OpenHalo 是重建的第三個內核。它提供了 MySQL 線纜協議兼容 —— 你可以同時用 MySQL 客戶端和 PG 客戶端讀寫同一個數據庫，這個能力非常有意思。

由易景羲和團隊開發，是少數幾家踏踏實實做事、并且愿意把成果開源出來的國產數據庫公司，很難得。這次更新的變化：

?版本從 PG 14.10 升級到 PG 14.18?版本號正式更新為 1.0，按照 Pigsty 打包規范重新調整了命名

雖然基線版本是 PG14，稍顯陳舊，但在 MySQL 遷移場景下確實是一個值得考慮的選擇。

在 Pigsty 中使用：configure -c mysql。

其余六位常駐選手

除了本次新增和重建的六款內核，Pigsty 還有六位一直在的"常駐選手"：

IvorySQL（pg_mode: ivory）—— 瀚高出品的 Oracle PL/SQL 兼容內核，目前基于 PG 18.1。

Percona TDE（pg_mode: tde）—— 透明數據加密，滿足合規場景中"落盤加密"的剛需。更新節奏稍慢于 PG 主線，后續會跟進到最新版本。

PolarDB（pg_mode: polar）—— 阿里開源的共享存儲架構 PG 內核，更新了小版本。

Citus（pg_mode: citus）—— 微軟出品的分布式擴展，正式發布 14.0.0 版本，支持 PG 18。

Ferret / DocumentDB（pg_mode: mongo）—— MongoDB 協議兼容方案，讓你用 MongoDB 驅動直連 PostgreSQL。

Supabase 自建模板也例行升級到了最新版本。

一份配置，十核齊飛

說了這么多內核，最好玩的事情其實是這個

我們做了一個 demo/kernel.yml 配置文件，

可以用這個模板一鍵拉起 10 個不同的 PG 內核。

每個集群都有獨立的監控面板、高可用、備份恢復，就像管理 10 個標準 PostgreSQL 一樣。純屬炫耀—— 看，俺能一鍵同時拉起這么多風味的內核。

不過這也是一個很好的參考模板：如果你想在一套 Pigsty 部署里混合使用多種內核，具體該怎么配置，看這個就對了。

企業級 PG 發行版

眼尖的朋友可能已經發現，網站首頁的 Slogan 換了。

以前叫 "Battery-Included, Local-First FLOSS RDS"，現在改成了："開箱即用的企業級開源 PostgreSQL 發行版，自帶高可用、PITR、IaC 監控與 461 個擴展"。

老馮之前一直不喜歡 “企業級” 這三個字，感覺似乎是比 “云” 還要狠的 “殺豬盤” —— 但奈何很多客戶就吃這一套。實際上老馮在 里面也提到了，有些標著企業級高可用的方案其實底下就是 “patroni”，企業級備份底下就是個 pgbackrest，甚至參數都沒優化過。既然如此，實力到位，該戴的帽子就應該理直氣壯的戴上。

另一個變化是去掉了"RDS 替代"的說法。以前叫自己"開源 RDS 替代"，是一種借力定位——用人們熟悉的品類錨點（云數據庫）來解釋 “Pigsty 是什么”。但到了今天，老馮有信心說：不需要用別人的東西來定義自己。Pigsty 就是 Pigsty，它應該自己開創自己的品類，而不是借用別人的定義。

從 GitHub Star 上看，Pigsty 已經是 Linux 原生賽道的 No.1，增長速度也開始重新與 EDB 老大哥的 K8S 云原生賽道 CloudNativePG 看齊。

順便一提，Pigsty 目前也算是中國開發者/廠商在 PostgreSQL 生態中最有影響力的開源項目了。

其他改進

除了內核大戲，v4.2 還有一些值得注意的工程改進：

Redis 目錄規范化：默認目錄從 /data 調整為 /data/redis。存量配置如果還用 /data，需要先改過來再升級，部署階段會阻止舊路徑繼續使用。

Configure 腳本優化：支持 -o 絕對路徑輸出并自動建目錄；區域探測改為三態（境內/境外/離線回退），修復了 behind_gfw() 卡住的問題。

pgBackRest 初始化容錯：stanza-create 增加重試（2 次、間隔 5 秒），緩解與 archive-push 的鎖競爭。踩過這個坑的人知道它有多煩。

Supabase 應用棧升級：PostgREST 14.5、Vector 0.53.0，S3 訪問密鑰變量補齊。

Vibe 模板更新：內置 @anthropic-ai/claude-code、@openai/codex、happy-coder 等工具，AI 編碼沙箱開箱即用。

基礎設施例行升級：Grafana 12.4、Prometheus 3.10、VictoriaMetrics 1.136、etcd 3.6.8、Kafka 4.2 等。注意 Grafana 12.4 有 data link 合并行為變化，自定義面板需檢查。

首頁改版：之前用 Claude Code 糊了一版，有人反映太丑了，批評得很有道理。這次讓 Codex 重新優化了一輪，好看不少。后面有空會繼續打磨。

后續展望

Pigsty 作為開源項目，我覺得已經達到了相當完善的程度。后續的工作重心會逐漸轉向子項目：

Pig CLI 最近更新了很多強大功能 —— 把 PostgreSQL、Patroni、PgBouncer、pgBackRest 的管理全部封裝成了命令行工具，方便 Claude Code 這樣的 DBA Agent 調用。這種同時為人類 DBA 和 AI Agent 設計的命令行工具，我稱之為 Agent-Native CLI。

DBA Agent 方面，最近寫了一些 Claude Skills 和提示詞模板，讓 Pigsty 環境可以被 AI 工具感知。這樣你就可以把 Claude Code 放進 Pigsty 環境里，讓它幫你干活。

Pigsty 本身會繼續跟著 PG 小版本的節奏走。下個版本可能會正式補上 Cloudberry 的部署劇本，加上本地 SMTP 服務器支持（maddy / stalwart）。大的新功能暫時不急 —— 當前這個架構持續穩定地跑下去，就挺好。

數據庫老司機

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

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

歡迎加入 PGSQL x Pigsty 交流群 (QQ 619377403)