版本与支持策略

版本号含义

从 PostgreSQL 10 起，第一个数字是 major，例如 18；点后的数字是 minor，例如 18.4。major 大约每年发布一次并带来新功能；minor 只包含错误、安全和低风险修复。

minor 升级不需要 dump/restore，通常替换二进制并重启；仍应阅读该版本 release notes。major 之间的数据目录不兼容，需要 pg_upgrade、逻辑 dump/restore 或逻辑复制迁移。

当前支持快照

截至 2026-08-02：

来源：PostgreSQL 官方版本策略。动态版本信息以该页为准。

上游版本不等于发行版软件包版本

发行版可能冻结 major，并在 16.14-1.el10_2、18+290ubuntu1 等完整版本号中记录打包 revision 和安全回溯。不能只截取开头的 16 或 18 判断漏洞状态；应使用发行版、release、repository、architecture 和完整 package version 共同定位，再核对厂商安全公告。

新项目怎么选

默认选择最新稳定 major 的最新 minor，除非驱动、扩展、托管平台或组织认证尚未支持。需要更保守时选择仍有充足支持窗口、且已被自身工作负载验证的 major；不要为了“稳定”新建即将 EOL 的版本。

PostgreSQL 19 在 2026-08 仍处于 beta 周期，不作为生产默认。测试新 major 时重点验证扩展、collation、备份工具、连接池、ORM、查询计划和监控采集器。

当前 Beta 状态、功能变化和逐项迁移风险见 PostgreSQL 19：新功能与 18 升级 19 指南。

支持矩阵应写进仓库

postgresql:
  supported_majors: [17, 18]
  tested_minor_floor:
    17: 17.10
    18: 18.4
  extensions:
    vector: "tested in CI"
  upgrade_owner: platform-database
  next_review: 2026-11-01

不要把 latest 当成部署策略。镜像、包和基础设施应锁定可审计版本，并由依赖更新流程推进 minor。

升级原则

• 总是运行所选 major 的当前 minor；继续运行旧 minor 往往比升级风险更高。
• 升级前读所有跨越版本的 release notes。
• 先在恢复出的真实数据副本上跑应用测试和查询计划对比。
• 扩展具有独立版本与升级脚本；分别检查。
• major 切换完成后重新收集统计并验证备份。