Pigsty v4.4 发布：统一运维入口 Pig 1.5、PG19 预览与 531 扩展齐备

July 23, 2026

Pigsty v4.4 正式发布。表面上看，这是一个例行维护版本：PostgreSQL 18.4、531 个扩展、PG19 beta，以及十四组通过验收的离线安装制品。真正值得讲的变化，则集中在软件仓库与命令行工具上。

Pig 1.5 完成了 PostgreSQL 日常运维命令行的重构。克隆数据库、分叉实例、执行时间点恢复——这些原来散落在 Ansible、Shell、Patroni 与 pgBackRest 里的动作，现在有了一套统一的命令行接口。

与此同时，官方重新梳理了仓库中的 PG 内核分支：新增 Babelfish PG18，补齐 pgEdge PG15～18、AgensGraph PG17 与 OrioleDB PG16～18，还为 PolarDB、IvorySQL 提供自行构建的软件包。

这一版还将 Supabase 自建模板跟进到上游最新版本，并解决了一批兼容问题；同时新增自托管云相册 Immich、堡垒机 JumpServer 与个人财务管理工具 Maybe 的一键部署模板。

Pig 1.5：统一运维入口

pig 最早只是 PostgreSQL 扩展包管理器，后来逐步承担 Pigsty 安装、软件仓库与 PostgreSQL 管理工作。到了 1.5，它已经不只是“能执行很多命令”，而是开始形成一套清晰的 PostgreSQL 操作界面。

这一轮最重要的变化不是命令数量，而是职责边界。过去，这些操作主要靠 DBA 记住 SOP 与命令别名：什么时候调用什么工具，下一步做什么，会有什么副作用。现在，这些经验被直接写进命令，高风险操作统一沿着同一条链路推进：

各阶段的结果与帮助信息既可以输出为人类可读的文本，也可以输出成便于机器和 Agent 处理的 JSON/YAML。通过这套 Agent-Native 接口，DBA、脚本与 Agent 可以共用同一个入口，获得所需上下文、风险判断与下一步提示。

抽象的话说多了没意思，下面来看几个具体例子。

克隆：给单个数据库开一个分支

新增命令 pig pg clone 可以快速克隆单个数据库。

pig pg clone meta meta_dev --plan   # 先查看计划
pig pg clone meta meta_dev -y       # 创建数据库副本

对于开发测试、数据分析、模型实验和 Agent 反事实推演来说，这种廉价分支非常实用。生产库保持不动，实验在副本里进行；做坏了直接删除，再开一个新的分支即可。详细用法可以参考《瞬间克隆 PostgreSQL 数据库，无需黑魔法[1]》。

分叉：给整个实例做一个沙箱

数据库克隆解决的是单库副本，而 pig pg fork 处理的是整个 PostgreSQL 实例，也就是 PGDATA 级别的物理分叉。

pig pg fork init dev --start        # 分叉为 /pg/data-dev 并启动
pig pg fork list                    # 查看本地分叉实例
pig pg fork stop dev                # 停止分叉实例

Pig 会为受管分叉写入元数据，并提供 list、start、stop、rm 等生命周期命令。在支持 CoW 的 XFS 上，分叉初始几乎不额外占用空间，后续只有新增或改写的数据块才会消耗容量。Pig 还会自动分配可用端口，让分叉实例与原实例并存。

它特别适合两类场景：一是在大规模、难回滚的操作前，留下一份低成本的本地分支；二是在事故恢复时拉起旁路实例，快速验证 PITR 目标与数据状态。

回到过去：恢复首先是一份计划

数据库恢复最危险的地方，从来不是缺一条命令，而是步骤太多、边界太模糊，而且人在事故压力下最容易犯错。

Pig 1.5 把低层恢复与高层编排明确拆开：

•pig pb restore 是 pgBackRest 的底层恢复原语，只负责文件与恢复目标。 •pig pitr 是面向 Pigsty/Patroni 环境的恢复编排入口，负责协调 Patroni、PostgreSQL 与 pgBackRest。

pig pitr -t "2026-07-10 12:00:00+08" --plan
pig pitr -t "2026-07-10 12:00:00+08" -y

恢复命令现在必须显式指定一个目标：最新状态、备份一致点、时间、LSN、事务 ID 或命名恢复点，不能把“没写目标”解释成某个危险默认值。结构化输出也不再充当确认；自动化执行破坏性操作时，必须明确传入 -y/--yes。

对于托管数据目录，pig pitr 会检查环境、停止 Patroni 与 PostgreSQL、执行 pgBackRest 恢复、按策略启动 PostgreSQL 并验证恢复状态，最后给出后续动作。

PostgreSQL 18.4、19 beta 与 531 个扩展

运维接口是这一版的主线，但发行版的基本盘也没有停下。

Pigsty v4.4 将 PostgreSQL 18.4 设为生产默认版本，同时增加一个精简的 PostgreSQL 19 beta 评估模板。PG19 beta1 尚未达到生产状态，v4.4 发布时使用的 pgBackRest 2.58 也无法识别它的控制文件格式，因此这套模板只用于尝鲜评估。

Pigsty 的 PG 扩展目录则从 v4.3 的 510 增加到 531。按方向来看，pg_ducklake 把 DuckDB、Parquet 与湖仓能力带进 PostgreSQL；pg_stat_plans 与 pg_stat_backtrace 补强查询计划和进程调用栈观测；升级后的 pgmnemo 与新加入的 psql_bm25s，则分别面向 Agent 记忆和 BM25 全文检索。

与此同时，OrioleDB 扩展到 PG16～18 并将 PG18 作为默认，pgEdge 覆盖 PG15～18，Babelfish 覆盖 PG17～18，IvorySQL 进入 5.x，AgensGraph 更新到 PG17，Cloudberry 与 PolarDB 也完成了路径和软件包重整。

这些细节看起来杂，但这就是发行版的工作：让 PostgreSQL 主线、扩展生态与内核分支同时保持可用、可安装、可升级。

应用更新：Immich、JumpServer、Maybe 与 Supabase

这一版新增了 Immich[2]、JumpServer[3] 与 Maybe 三个应用模板，并更新了 Supabase。

Immich：把照片库交给真正的 PostgreSQL

Immich 是一套开源的自托管照片与视频管理服务，可以把它理解成自己家里的 Google Photos 或 iCloud Photos。它有移动端自动备份、相册、地图、人脸识别和语义搜索，后端同时用到 PostgreSQL、向量检索、缓存和机器学习服务。其中，智能搜索与人脸识别需要 VectorChord 扩展 vchord，Pigsty 可以直接提供。

Immich 目前仍将照片原件存放在文件目录中，不直接支持对象存储。如果需要把存储池独立出来，可以用 JuiceFS 将 MinIO 或 S3 挂载为本地文件系统。

JumpServer：把堡垒机也接进来

堡垒机是许多企业的刚需，JumpServer 则是常见的开源选择之一。JumpServer 4.x 使用 PostgreSQL 保存核心元数据，因此 Pigsty 顺手补上了相应的部署模板。

Maybe 也在这一版加入应用目录，它是一套个人财务与资产管理工具。三个模板方向不同，但思路一致：应用可以跑在容器里，数据不必跟着容器一起漂。

Supabase：更新不只是换镜像

Supabase 更新很快，也是 Pigsty 应用模板里组件最多、兼容性最容易出问题的一套。v4.4 把 Studio、Auth、PostgREST、Realtime、Storage、Analytics、Edge Runtime 等组件跟进到 2026 年 7 月的上游版本，并做了一轮配套调整。

这次官方把 Analytics 放进独立的 _supabase 数据库与 _analytics 模式，避免日志分析表和业务对象混在一起；为 Studio 补齐 pg_stat_statements 兼容视图，让查询性能页面能够正常工作；同时适配新的 Publishable Key 与 Secret Key，调整 Kong 路由、Realtime 敏感接口、S3 兼容接口和服务健康检查。

Supabase 这种应用，单个容器能启动没有意义，十几个组件能一起升级、一起工作才算完成。v4.4 修的就是这些不起眼、但会直接决定模板能不能用的问题。

VIP 网卡终于不用手填

另一个令人喜爱的改动，是 VIP 网卡自动识别。

过去 vip_interface 与 pg_vip_interface 默认写成 eth0。如果要启用 NODE/PG VIP，需要用户手工配置网卡名称，比较繁琐。

v4.4 添加了自动检测，把默认值改成了 auto：Pigsty 会根据清单里的节点 IP，反查它实际所在的网卡，再把结果交给 Keepalived 或 VIP Manager。手工指定仍然保留，但大多数用户再也不用先登录机器跑一遍 ip addr，然后回来填写参数。这个功能只有几行配置，却能直接避免一类部署失败。发行版的体验，往往就是由这种小事决定的。

备份默认改用 Zstandard

此前，pgBackRest 默认使用 LZ4 压缩。LZ4 速度快、吞吐高，依然适合 wal_compression；但备份仓库更看重压缩比，因此 v4.4 将 pgBackRest 的默认算法改为 Zstandard。实际测试中，只增加少量解压开销，就能让压缩比从 2.x 提升到 3.x，额外节省约三分之一的备份空间，这笔买卖很划算。

这次切换也暴露出一个问题：IvorySQL 官方内核没有添加 --with-lz4、--with-zstd 等构建参数，无法使用 LZ4 与 Zstandard。这也直接推动了下一项改造：统一构建 PG 内核分支。

更好的首页，网站，文档

正值 Fable 与 GPT Sol 5.6 发布之际，Pigsty 也用 SOTA 模型审核 Review 了几遍，修复了若干问题，解决了文档中过时的部分。首页和文档站的样式也焕然一新。

统一构建 PG 内核分支

Pigsty 支持了许多不同风味的 PG 内核，其中 PolarDB 与 IvorySQL 此前直接使用上游构建的软件包。IvorySQL 的官方构建缺少几个关键编译参数，PolarDB 则缺少 Ubuntu 26.04 软件包。这两个问题官方都提交给了上游。目前，PolarDB #650[4] 的 Ubuntu 26.04 构建支持已经合入，IvorySQL #1377[5] 也确认会在下一个版本补齐相关选项；上游成品包则还要再等一次发布。

冯若航可等不了那么久。既然官方已经自行构建了这么多内核分支，也不差这两个，正好借此一劳永逸地统一 FHS 布局。以 PolarDB 为例，上游包名是 polardb-for-postgresql，默认安装在 /u01/polardb_pg_17；Pigsty 的包叫 polardb-17，安装在 /usr/polar-17。默认端口、运行时搜索路径、开发头文件与扩展构建工具，也一并整理到位。

为了让 PolarDB 的构建可以稳定复现，官方还把它依赖的 PFSD 开发库单独打成 polarstore 软件包。开源版同时移除了 PolarDB Oracle 兼容内核及其专用监控配置，不再将这条闭源兼容路径列为内置支持。

做这件事也是在为下一步提前准备。目前，Pigsty 的 500 多个扩展主要面向原生 PostgreSQL 内核。接下来，官方希望把“5 个原生 PG 大版本 × 16 组 Linux 平台（含仅在线支持的 EL8 双架构）”的构建矩阵，进一步拓展到十余种 PG 内核分支，让它们也能接入完整的 PG 扩展生态，而不是各自在 RPM 或 Docker 镜像里零散捆绑几个扩展。这才是 Meta Distribution 该有的样子。

写在最后与未来展望

做发行版，大部分工作都不适合拿来做漂亮的演示：改包名、理目录、补依赖、修构建脚本，再把十四组部署测试全部跑一遍。可一旦这些事情没人做，“开箱即用”就只是一句广告。

把上游的多样性收进同一套工程约定，把最后一公里的麻烦留给发行版。 这就是 Pigsty v4.4。

Pigsty 4.4 完工之后，团队已经开始筹备 5.0 版本。在 5.0 版本之前，可能会有一个 4.5 过渡版本。

5.0 版本将随着对今年九月份 PG19 的完整支持一同发布。Pigsty 19 引入了非常多强大的新功能特性。为了充分利用好这些功能特性，Pigsty 5.0 将进行针对性的调整。一些准备工作已经完成。比如这次的 pg_exporter 更新到了 1.3.0，提供了对 PG-19 新监控指标的支持；一些 Patroni 参数模板也都已经为 PG-19 的修改预留好了位置和占位值。

Pigsty 5.0 将会有一个专门的企业级软件制品仓库，采用和开源版有所不同的策略：采用更为保守的更新策略，会保留所有的历史版本软件包、Debug 包、修复包，并定期提供快照。为了实现这个目标，还专门做了一个仓库管理工具，用来统一 APT 和 DNF 两侧的仓库管理。该工具取名为 sow（母猪），正好和包管理器 Pig（小猪）相互对应。

此外，团队还在进行一些有趣的尝试。比如说用 Go 重写 Patroni，至少第一阶段先重写 Patroni 的客户端工具，从而提供更好的管理体验。这个项目取名 Boar（公猪），与 sow（母猪）和小猪正好凑成一家子，在 Pigsty 里相映成趣。