PostgreSQL 版本选择指南：从版本号机制到升级策略

如果你打开 PostgreSQL 官网的下载页面，盯着那一排版本号犹豫超过三秒，那这篇文章就是给你写的。PostgreSQL 版本选择从来不是“下载数字最大的那个”这么简单。我在做数据库选型和日常维护时，见过太多人要么死守某个老版本不敢动，要么刚发新版就往生产环境冲，最后被兼容性问题弄得焦头烂额。这篇文章会把版本号机制、不同场景下的选择策略、功能生态的约束、安装时的常见坑，以及旧版本升级到新版本的完整思路梳理清楚。无论你是第一次接触 PostgreSQL，还是正在规划一次大版本升级，都可以照着这份清单走一遍。

顺便说一下，文里的命令和步骤我都按实际运维场景来写，不搞花架子。涉及版本支持周期这类有时效性的信息，我会给判断方法，具体年份和 EOL 日期请以官网生命周期页面为准。

1. 先看懂版本号：主版本、小版本与支持窗口

1.1 10以后的版本号变化：为什么没有PostgreSQL 10.0

很多新手不解：为什么网上有人说 PostgreSQL 9.6，有人说 PostgreSQL 16，还有人下载到 postgresql-16.2.tar.gz，这些数字到底是什么关系。

PostgreSQL 在 10.0 之前，版本号是“大版本.小版本”的结构，比如 9.6 算一个大版本，9.6.1、9.6.2 才是补丁版本。从 10 开始，官方把版本规则变了：主版本直接用 10、11、12……这样递增，每年秋季左右发布一个大版本，后续的安全更新和 bug 修复则通过类似 16.1、16.2 这样的小版本号发布。简单说，16 是功能版本，16.2 是 16 这条线上的补丁版本。

这里有个容易混淆的点：PostgreSQL 不会像某些商业数据库那样，把一个主版本维护十几二十年。官方给每个大版本提供大概五年的维护窗口，过期之后就不再发布补丁。也就是说，主版本号越大并不代表支持窗口越长，也可能这个版本已经快走到生命周期尽头了。

判断一个版本是不是“当前主流”，不是看它数字多新，而是看它是否还处于官方支持期。打开 PostgreSQL 官网的 Versioning Policy 页面，你一眼就能看出哪些版本是 actively maintained，哪些已经 End-of-Life。

1.2 五年版支持窗口与项目生命周期的匹配

“五年维护窗口”听起来很长，但放到企业项目里其实转瞬即逝。一个系统从设计、开发、上线到稳定运行，很可能超过三年，如果在选型时选了一个已经发布四年的版本，那系统还没跑热，数据库官方补丁已经停了。

所以我的建议是：拿你项目的预计生命周期去匹配版本的剩余支持期。如果项目计划运行三到五年，那就选一个发布不超过一两年、仍在官方支持期内、且有足够缓冲区的版本；如果项目只是做短期的原型验证或者内部工具，选当前最新版也没问题。

简单整理一下判断逻辑：

有人会问：如果我的项目已经使用了 PostgreSQL 13，而 13 已经临近 EOL，是直接升到 17 还是每两年升一次？这个问题没有标准答案，但有一条经验值得参考：不要为了“少升一次”而跨度过大。数据库大版本升级涉及的不仅是内核本身，还有所有依赖它的插件、监控脚本、备份工具、应用程序连接串里的参数行为。目标版本和当前版本跨度越大，回归测试的范围就越广。

1.3 奇偶版本号不用过度解读

PostgreSQL 早期是存在“开发版/稳定版”的奇偶区分的，比如 9.5 时代之后会有一个 9.6 的迭代周期。但进入 10 之后，官方不再采用“奇数版本是开发版、偶数版本是稳定版”这种简单的二分法。每年发布的大版本，在发布时都是社区认为质量足够好的“稳定版”。

不过，确实有“第一版”和“第几个补丁版”的成熟度差异。PostgreSQL 新的大版本发布初期，虽然核心代码已经经过长时间的 beta 测试，但周边生态很容易滞后——比如某个插件今天才刚验证支持 17，某些公司内部的自动化脚本可能还只适配到 16。这也是为什么很多生产项目不会在 PG 新大版本刚发布那天就立即上线，而会等它出到 .2、.3 后再评估迁移。这是实践策略，不是版本号本身的诅咒。

2. 不同使用场景的版本选择策略

2.1 全新生产环境：求稳也要有新特性

如果你是从零开始搭建一套生产库，我建议这么选：选择一个已