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)