Pigsty v4 發布：進入 AI 時代

Pigsty v4.0 發布了！ 這是一個具有里程碑意義的大版本。

Pigsty 是一個開箱即用、開源且本地優先的 PostgreSQL 數據庫發行版。它能讓你在沒有數據庫專家的情況下， 在本地快速搭建企業級的 PostgreSQL 數據庫服務，自帶監控、備份、高可用、IaC、連接池與 444 個擴展插件。

v4.0 是一次重大的架構升級，由 320 個 Commit 組成，有著將近 40 萬行代碼的變動（雖然其中三十多萬行是監控面板）。 我認為這個版本可以稱之為 "Finished Software" —— 它已經達到了一個讓我自己滿意的完工狀態。

v4.0 的主題是：更開放、更高效、更安全、更智能。 下面我們會介紹一下 v4.0 的新特性，以及未來發展的展望。

太長；不看

?協議變更：回歸 Apache 2.0?監控煥新：Victoria 全家桶上位?容器支持：Docker 黨的福音?PG 18 就緒：444 個可用擴展?安全加固：密碼，防火墻，SELinux?JUICE 模塊：把數據庫當文件系統?VIBE 模塊：Claude Code 運行時?DBA Agent：Skills 與命令行?高可用優化：RTO/RPO 拆解與權衡?瞬間克隆：瞬間復刻數據庫與實例?IaC 增強：更多精細的定制旋鈕?Vibe 實戰：九成代碼由AI編寫?完工軟件：質量達到滿意狀態?進入 AI 時代：為 Agent 而生

協議變更：回歸 Apache

Pigsty v4.0 重新從 AGPLv3 許可證改回了 Apache 2.0 寬松許可證。 對于用戶來說，當你在公司使用時，就不需要再和法務去 Battle 了，ISV 也可以用它放心地集成，作為各類軟件與項目的底座。 如果你想做一個自己的定制 PG 發行版，也完全可以在 Pigsty 的基礎上進行，避免重復造輪子。

關于變更的細節，這里就不展開討論了，老馮專門寫了一篇文章討論這個事。

監控煥新：Victoria 全家桶上位

v4 最標志性的改動是用 替換掉了 Prometheus 和 Loki，并添加了 Tracing 能力。

VictoriaMetrics 是 Prometheus 的上位替代品，我們幾年前在探探就大規模用過，效果驚人，用幾分之一的資源實現了幾倍的效果。

這次切換的契機是 Loki 表現不佳，而它配套的日志收集 Agent Promtail 今年也將被棄用。 我選擇了目前最好的方案：VictoriaLogs + Vector，順便也把 VMetrics + VTrace 帶上了。

效果立竿見影：以前拉取一天的日志需要轉圈等待，現在 VictoriaLogs 基本秒出。 我們將所有日志收集遷移到 VictoriaLogs，設計了與 Prometheus 一致的標簽體系，給各組件補齊了日志監控。 各個組件都添加了 Logs 與 Panels，還新增了 Node Vector、Node Juice、Claude Code 等全新儀表盤。

架構上也做了簡化：原本需要通過 Nginx 給不同組件掛載不同端點，現在所有組件統一掛載在一個 Nginx Server 上。 你不再需要區分域名和端口，一個域名甚至直接用 IP 就能訪問 Grafana、日志系統、監控指標和 Alertmanager。 企業版還提供了自動漢化功能，將每個指標的標題、描述都翻譯成中文，并補充了使用和解讀說明。

從整體上來看，當下的 INFRA 模塊，就像是一個 Victoria 發行版，Metrics + Logs + Trace + Alert + 統一 UI 入口。 配上開箱即用的 Grafana，就能讓你輕松擁有一個企業級的可觀測性平臺。

容器支持：Docker 黨的福音

Docker 容器支持，應該是社區呼聲最高的功能 —— 讓 Pigsty 本身跑在容器里。 以前雖然能實現，但需要手動修改參數，對基礎鏡像和 Systemd 配置有技術門檻。 現在，我們直接提供了官方基礎鏡像，只要你有 Docker，一鍵就可以拉起！（前提是你的 Docker Hub 已經翻好了）

cd ~/pigsty/docker; make launch

在鏡像設計上，我糾結了很久，是交付一個裝好了所有東西的鏡像，還是一個可以部署的精簡鏡像。 最后我選擇了后者，基于 Debian 13 官方鏡像，添加了 systemd、ssh、sudo 以及 pigsty 本體，其他東西都交由 deploy 部署階段在線完成。 這樣基礎鏡像的大小就只有 200 MB 左右（否則是 3 GB）。

部署完成后，你就可以正常使用了，默認使用本地的 8080 端口提供 web 服務；2222 端口提供 ssh 訪問；5432 端口提供數據庫訪問。 無論是 Windows，MacOS 還是 Linux，都可以輕松拉起，快速嘗鮮。

PG 18 就緒：444 個擴展嚴陣以待

Pigsty v4 的一個核心目標，就是確保 PostgreSQL 18 為嚴肅生產做好完全的準備。 在這一輪發布周期中，我們為 TimescaleDB、ParadeDB、Citus、DocumentDB、AGE 這樣的主要擴展添加了 PG 18 支持。

為了實現這一點，我們為 14 個 Linux 上的 6 個 PG 大版本編譯了約 226+ 擴展包，讓可用擴展的總數達到了 444 個，同時還修復了不少 PGDG 中缺失的擴展組合。 還額外包括了 10 個全新的擴展：

與此同時，我們還進一步優化了 PG 的默認參數配置策略。 例如，允許用戶配置新增的 io_method 以充分利用異步 IO 能力，并且啟用了 file_copy_method = clone，以實現對 “” 的支持。 PG 17/18 的新增參數和之前的老參數，我們都認真仔細地重新梳理了一遍，并根據更新過的業界最佳實踐提供了表現良好的默認值。

同時，提供 Oracle 兼容性的 IvorySQL 內核與 TDE 透明加密的 Percona 內核都提供了 PG 18 的版本支持。 提供 MongoDB 兼容性的 FerretDB 在我切換至微軟的 DocumentDB 版本后，也提供了 PG 18 的支持。

總而言之，PG 18 的主要擴展都已經正式就位，參數也已經充分利用并優化完畢，監控指標也完整收集處理。 Pigsty 中的 PG 18 已經可以以全盛狀態，進入嚴苛的生產環境使用！

安全加固：密碼，防火墻，SELinux {}

Pigsty v4 也在安全方面做了大量工作，對照等保，SOC2 等合規標準，基本實現了所有能做的安全合規點。 幾個值得一提的改進：

隨機默認強密碼：經常有用戶部署直接用默認密碼，這次我們新增了 configure -g 選項，自動把所有默認密碼替換成隨機強密碼。

ETCD 啟用 RBAC：以前全局用證書認證，現在每個 PG 集群一個自己的 etcd 用戶密碼。 管理節點可以管理所有集群，普通數據庫節點僅能管理自身所在的集群，避免串臺干擾。

SELinux 規則優化：以前默認關閉，現在 EL 系統中基本的安全上下文都已配置妥當，默認為 permissive 模式，可以直接按需 enforce。

防火墻默認支持：現在支持定義公網開放端口，內網網段。 即使云服務器沒有提供安全組，你也可以自己用簡單的方式將暴露面縮小到最小狀態（默認開 ssh 22，http 80，https 443，按需 pgsql 5432）

此外，我們還梳理了所有用戶和文件的權限屬主模型，把所有數據聚攏在統一目錄（/data）下（方便 Docker 掛載）。 根據不同用戶組拆分權限，完全遵循最小權限原則。

最后，這些安全策略都是漸進式的：默認配置下只要隨機生成了強密碼，就已經足夠安全了。 而更多高級安全選項，則供企業用戶根據自己的實際情況進行利弊權衡與選用。

JUICE 模塊：把數據庫當文件系統

v4 新增的 JUICE 模塊集成了 JuiceFS，可以把對象存儲和 PostgreSQL 掛載成本地文件系統。 最厲害的玩法是把數據和元數據都放到同一個 PG 里，實現文件系統和數據庫的一致性 PITR， 詳見《PGFS：將數據庫作為文件系統[18]》。

這解決了一個實際痛點：一個應用既有文件系統（存放知識庫文件），又用了數據庫。 回滾時數據庫 PITR 容易，文件系統難，兩者保持一致更難。 現在你可以把文件全部存到數據庫里，實現整個系統的同步時間點回滾。

這種能力對 Agent 特別有用。 你可以在掛載目錄上進行 Vibe Coding，所有修改實時存儲在數據庫中，相比 Git 手動快照的方式，可以瞬間回滾到任意歷史時間點。 以前只有高端商用 CDP 設備才有這種能力，現在 Pigsty 免費提供。 在 PIGLET AI 沙箱里面，就默認配置了這個功能。

VIBE 模塊：Claude Code 運行時 {}

VIBE 模塊為 Vibe Coding 準備，是完全可選的。 它配置好了 Node.js、Claude Code，還有 VS Code 和 Jupyter，都可以直接從瀏覽器訪問。 此外，還有 uv python 包管理器，npm，golang，hugo 等常用工具。 中國區域的部署，還會自動配置 Python/Node 的鏡像源，安裝速度快，不需要翻墻。

最妙的是，我們還準備好了完整的 Claude Code 環境，可以一鍵幫你下載并配置好最新版本。 只需 等，提供了各種便利的快捷方式，可以讓 Claude Code 以 Sandbox 模式 YOLO 運行。 還提供了一個，能讓你實時了解你的 Agent 正在干什么、想什么。 甚至還帶了個 happy + tmux，讓你能很方便的用手機語音指揮 CC 干活。

VIBE 模塊還可以和 Juice 模塊配合使用，例如在 PIGLET.RUN 沙箱環境中就是這樣做的： 把你的代碼目錄整個通過 JuiceFS 模塊掛載到數據庫里，就能利用數據庫的時間點恢復能力，一鍵將文件系統和數據庫同時回滾到任意時間點。

這個模塊是給 PIGLET.RUN 準備的，也是老馮自己在云端寫代碼開發時使用的環境。 裝好之后，你等于有了一個完整的云上開發環境，足夠安全，而且工具齊備。

DBA Agent：Skills 與命令行

VIBE 這個模塊，并非只是拿來搞開發用的。 它的真正用途是為老馮在做的 DBA Agent 打基礎 —— 其實你現在用這個模塊裝好 Claude Code 之后，它已經能夠在 Pigsty 環境里面做一些很有價值的事情了。 幫你巡檢數據庫，出個報告，優化查詢之類的問題，都不在話下。

我之前寫過一篇 PostgreSQL 快速上手教程：安裝 Pigsty，運行 Open Code 調用 GLM-4 模型，讓它扮演老師指導學習。 用戶反饋效果驚人，一些 DBA 試用后說"這玩意兒怪嚇人的"——給它丟個巡檢任務，沒做額外配置就能干得相當出色。

當然，讓 Agent 在生產環境放手大干還是過于激進，所以硬性規則還是需要仔細配置的：哪些操作絕對不能做，哪些必須人工確認，權限如何劃分。 我們在 pigsty 家目錄里面已經有了一個基礎的 CLAUDE.md[21] 告訴 CC 什么能做，什么不能做，你在這個目錄里面啟動，就可以啟用它。

Pigsty 做 DBA Agent 有一個得天獨厚的優勢，就是它的上下文與環境是高度確定，而且是用代碼清晰描述管理的。 Pigsty 從第一天就堅持 IaC（基礎設施即代碼） + CLI（命令行工具） 的理念，只將圖形界面用于監控系統，而非管控。

因為我們相信程序化，智能化管理的終局就是 IAC + CLI。 因此 CC 只需簡單讀取 pigsty.yml 配置文件，就能知道你的環境中有什么模塊組件，如何訪問與使用。

而一個簡單易用的 AgentNative CLI，更是會讓 DBA 和 DBA Agent 如虎添翼。 這次跟著 Pigsty v4 一起發布的 pig v1.0[22]，就提供了許多這樣的能力封裝，將原本復雜的命令與操作序列，組織為傻瓜 / Agent 都會用的命令，后面將專門寫文章介紹。

高可用優化：RTO/RPO 拆解與權衡

除了 AI4PG 和 PG4AI，Pigsty v4 也在數據庫服務的核心基本功上做了很多優化。 之前也在 《》這篇文章中詳細介紹過。

Pigsty 用戶的場景很廣泛：同機柜部署、跨機房容災、跨大洲架構（延遲 200ms+、高丟包）。 這些場景對高可用參數的要求完全不同。

以前我們只是共用一套調整了的 Patroni 參數集，而這次我們針對幾種不同的情況，提供了四種預制的參數模板。

同理，我們也照著 Oracle 的數據保護模式，提出了三種典型的 RPO 模板，供用戶在數據一致性與性能/可用性之間進行利弊權衡。

有意思的是，當我們深入研究這個主題的時候，我們發現市面上絕大多數基于 Patroni 的高可用方案使用的都是默認參數，也沒有人詳細分析過 RTO 的組成。 所以這里我定量分析了幾種故障路徑下 RTO 的詳細組成，并確保這幾組參數的最劣情況 RTO 不超過指定上界。 用理論分析，確保用戶在用 Patroni 高可用的時候，做到心里有數、安心放心。

用理論拆解的方式，將四組參數的 RTO 上限控制在 30/45/90/150s 內

不僅僅是高可用有改進，在 PITR 上也有了顯著的優化 《 》。 PostgreSQL 18 帶來了瞬間克隆能力，這是 AI 應用特別需要的：快速、低成本地 Clone 一個副本。

生產庫可能幾百 GB 甚至幾個 TB，不可能直接在上面做測試。 Fork 采用 COW（寫時拷貝）技術，即使超大型數據庫也能在 200 毫秒左右完成克隆。 最酷的是克隆后存儲空間不變：兩個 100GB 的數據庫，總占用依然是 100GB。

pg-meta:
hosts:
10.10.10.10: { pg_seq: 1, pg_role: primary }
vars:
pg_cluster: pg-meta
pg_version: 18
pg_databases:
- { name: meta } # <----- 待克隆的數據庫
- { name: meta_dev ,template: meta , strategy: FILE_COPY}

如果使用 XFS 文件系統（Linux 主流默認），還能獲得實例級別的瞬間克隆能力：瞬間克隆出一個大實例，不占用額外存儲，不影響線上業務。 再加上經典的集群 PITR 能力，總結起來，你可以在實例、數據庫、集群三個層面快速克隆 PostgreSQL，并回滾到保留期內的任意時間點。

為了進一步降低 PITR 的門檻，我們還把 PITR 能力做到了 pig 里：運行 pig pitr，它自動幫你傻瓜式地處理一切。 將數據庫集群以原地/增量/快速高效的方式，恢復到你指定的目標點。 這樣，無論是新手還是 AI Agent 都能輕松利用起來，門檻就得做到這種程度才夠勁。

IaC 增強：更多精細的定制旋鈕

以前 Pigsty 不提供刪除用戶和刪除數據庫的能力，因為刪除操作很危險，涉及清理依賴對象和權限的復雜 SOP。 但用戶確實有這個需求：配置復雜資源搞糊了，想刪掉重來。 這次我們實現了刪庫和刪用戶功能。 不要小看刪除用戶這樣的功能 —— 看似簡單，實際上要做好非常難：幾乎所有的云數據庫服務，都只支持很簡單的刪除 "裸用戶"，一旦用戶身上掛著依賴，系統直接報錯。

v4 也調整了 IAC API 設計，新增并對齊了直到 PG 18 的新增可用參數。 例如，在用戶層對角色繼承的三個選項 ADMIN, INHERIT, SET 提供了定制支持。 你也可以為數據庫指定額外的 Locale 參數，并指定 state 用于刪除或者重建數據庫與用戶，以及數據庫內的 Schema 和 Extension。

現在 HBA 規則定義支持了額外的 order 字段，這意味著你可以明確指定每條規則的優先級順序。 同時內網網段的定義，也可以進行定制與修改了，并與默認防火墻策略保持一致。 PG 有了自己專門的 Crontab 列表，與系統的全局定時任務區別開來。

此外，我們還改善了許多細節，對幾乎所有的參數位點都做了防注入處理，并單獨處理了一些 PG 特殊的列表參數，細節就不過多展開了。 最終的效果是，你可以用 IaC 的方式定制 PostgreSQL 集群里面的各種細節。 從數據庫，用戶，繼承關系，權限，HBA，服務，到擴展，模式，一步到位，拉起可以直接供業務生產就緒的數據庫集群。 而且這種 IaC 配置文件定義的方式，對于 DBA 與 DBA Agent 來說，都非常自然友好。

Vibe 實戰：品味與驗收是護城河

最后來聊一下 Pigsty v4 的工程實踐吧，Pigsty v4.0 中 九成以上的代碼都是 Claude Code 編寫的。 我只負責三件事：提出思路，設計 API，驗收結果。方法論分四個階段：

設計：扮演產品經理，與 AI 探討生成設計文檔。API 設計的品位 CC 還不夠好，這部分必須親自操刀。

實現：新 Session 讓 AI 實現代碼，完成后讓它進行 10 輪自我反思與修正，每輪給出評審意見直至滿意。

Review：開啟另一個 Session，讓 AI 在虛擬機沙箱中進行自動化測試。

驗收：最后手工測試驗證。

Claude Code 像一個聰明但略缺領域經驗的天才實習生。 只要你的直覺正確、方向對了，它就能把細節做得很到位。 這種老帶新結對編碼效率很高，我通常并行推進三個 User Story —— CC 寫代碼極快，瓶頸卡在我身上。

通常確定設計方案之后，CC 的一次出活率能到 90%+，剩下 10% 就要多次迭代優化拉扯了。 特別是對于 RDS 這種幾乎沒有公開資料的領域，需要各種人工指導才能達到最終的滿意效果。

Claude Code 有兩件事情做得還不太理想： 一是 API 設計，這個還是需要品位來把關，CC 只能提供一些思路與建議； 二是驗證效率，目前瓶頸在于人工驗證的速度（卡在我身上），因為執行冒煙測試 SOP 太慢。

這給我一個啟示：在 Agent 編碼時代，設計的品味與驗證的能力才是真正的護城河。 硬核項目即便開源了代碼，絕大多數人既沒有二次開發能力，更缺乏 QA 能力——這才是壁壘所在。 代碼會越來越 "便宜"，但 "把正確的東西做對" 依然昂貴。

這讓我想到 SQLite 的模式：源代碼公開在 public domain，但核心測試套件 TH3 是專有的。 在 AI 助手加持下，一個超級個體就能頂一個滿編團隊，引入外部貢獻反而會拖慢節奏。 所以，Pigsty 也將采用類似路線：Open Source, but not Open Collaboration —— 只接受 Issue、特性請求與反饋，不再接受 PR。

完工軟件：質量達到滿意狀態

正如《》里說過的，我能給 v4.0 這個版本打一個 90 分的水準。 SOTA AI 給出的結論也基本差不多：在 PostgreSQL 服務質量上，免費的 Pigsty 已經優于頭部云 RDS ，在開源方案中也達到了頂尖水準。

所以老馮覺得也差不多了，在文章開頭說，Pigsty v4.0 可以稱之為 “Finished Software”。但 “完成” 不是 “歸檔”。軟件的生命周期里，Finished 意味著它已經足夠好、足夠穩定、足夠讓人放心地用于生產。 就像一把好刀，開刃完成了，接下來是長期的使用、保養、傳承。

Pigsty 我會持續維護下去——Bug 修復、版本跟進、擴展打包，有 AI 幫助這些工作不費多少時間，每年跟進一個 PG 大版本就好。 剩下的 10 分，留給生態、產品、商業服務去生長。

而我的精力，終于可以騰出手來，正式轉向那個三年前就埋下的伏筆。

進入 AI 時代：為 Agent 而生

三年前，老馮寫下 《》 ，就已經將 智能自治數據庫 列為終極目標。 彼時這只是愿景，而今天，它真正成為可能。

Pigsty 從第一天起就堅持 IaC + CLI，把 GUI 只用于觀測而非管控。很多人不理解：為什么不做個漂亮的控制臺？

現在答案很清楚了——因為我們在等 Agent。

Agent 不需要點按鈕，它需要讀配置、調 API、執行命令。Pigsty 的架構天然為程序化管理而生。 當別人還在琢磨如何讓 AI 操作圖形界面時，Pigsty 用戶已經可以讓 Claude Code 直接讀取 pigsty.yml，理解整個基礎設施，然后動手干活了。

這就是"進入 AI 時代"的真正含義：不是給軟件加個 AI 功能，而是讓軟件本身成為 AI 的原生棲息地。

為此，我準備了兩翼：

PIG —— 原本只是個包管理器，在 v1.0 中重新定位為 PostgreSQL 生態的 ， 完整接管數據庫、連接池、高可用、備份、接入的全生命周期。它是 Agent 操作 PostgreSQL 的雙手。

PIGLET.RUN —— 一個以 PostgreSQL 為中心的 Agent 運行時。 輕量化的 Pigsty 子發行版，用戶動動嘴，就能生成完整的、帶有數據庫的復雜應用。它是 Agent 棲息的土壤。

而 Pigsty 本身，要成為那個讓你在 AI 時代依然保持確定性的基礎設施底座 —— 敢讓 Agent 放手干活，也敢在它干錯的時候一鍵回到昨天。

用 IaC 描述它，用觀測理解它，用權限約束它，用 PITR 糾正它。 這不是 “又一個 PostgreSQL 裝機腳本”，而是一整套把復雜系統關進籠子里的工程方法。

數據是系統的命脈，數據庫是守護命脈的心臟。

Agent 正在成為新的生命形式。它們會思考、會行動、會犯錯、會學習。

而每一個生命，都需要一顆可靠的心臟。

Pigsty v4.0，為 AI 時代而生。

歡迎入局。

數據庫老司機

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

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

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