距离 PostgreSQL 14 停止支持还有两个月：比起升级，先练习回滚
有些团队定好了数据库版本升级的时间表，却不知道升级失败时回滚需要多久。如果您正在运行 PostgreSQL 14，现在需要的产出物不是一个新版本的名字，而是一个能够回滚的迁移计划。截至 2026 年 9 月 14 日，距离官方停止支持日期大约还有两个月。
已确认的事实：社区支持与托管合同不同
PostgreSQL 官方版本策略对大版本提供 5 年支持，并将 14 的最终发布日期定为 2026 年 11 月 12 日。这是社区支持的时间表。托管服务的升级窗口、单独的延长支持以及费用，必须另行在相应厂商的文档和合同中确认。
同一大版本的小版本更新与大版本升级也必须区分开来。应用 14 的最新修复版本不能代替迁移到 15 或更高版本。反之，仅凭已有大版本迁移计划为借口，不断推迟应用当前版本所需的修复程序也是不恰当的。
第一项产出物：比起数据大小，更重要的是依赖清单
从这里开始不再是官方支持政策本身，而是实际运维建议。首先将各个服务的 DB 版本、扩展模块及版本、连接驱动、批处理任务、备份保留位置、复制架构整理到一页纸上。确定目标版本时，不能仅仅因为它是最新版就草率选定，还要同时确认实际托管环境和扩展模块的支持范围。
仅仅假设“DB 较小所以速度会快”是不够的。如果登录后的首次查询、支付状态更新等核心业务路径中所使用的扩展或查询发生了变化，即便数据复制时间很短，迁移也可能会失败。找出无人负责的依赖项，正是这份清单的目的所在。
第二项产出物：比起备份成功信息，更重要的是恢复结果
在隔离环境中恢复最新的备份，并运行应用程序具有代表性的读写流程。在此演练中，必须首先确认连接目标，以避免向生产 DB 发送写入。包含实际数据的恢复副本，应在原有的访问控制范围内进行处理。
将备份开始时间、恢复完成时间、验证完成时间区分开来，就不会将获取文件的时间与服务可以重新写入的时间混为一谈。与其只通过人为缩减、运行极快的小样本，不如用接近生产规模的恢复副本测量时间，并记录成本和空间限制。
pg_upgrade 检查通过不能替代服务验证
官方 pg_upgrade 文档说明，可以通过 --check 在实际升级之前执行兼容性检查。外部模块的兼容性需要另行考察，并且还需要与新服务器相匹配的共享库。切勿仅凭检查命令执行成功，就认为应用程序的查询和性能都已得到验证。
特别是 --link 模式存在限制：启动新集群后，原集群将无法直接继续使用。如果仅仅看重速度而选择该方式，原本预想的回滚路径可能会不复存在。必须在与实际迁移方式相同的条件下进行排练，并明确需要基于恢复进行回退的时机。
在恢复写入之前需要决定的标准
为了避免在迁移当天临时协商，应提前书面约定成功标准。例如，可以将核心 API 读写完成、无重复处理地恢复批处理、主要业务表的汇总一致、复制状态确认等与负责人对应起来。这并非强制要求所有服务使用完全相同的基准值示例。
在新 DB 开始写入后若要退回先前的备份，期间的变更如何保留也会成为问题。不能将仅仅启动旧服务器的过程与不丢失数据恢复的过程混为一谈。可接受的数据损失与停机时间范围，必须由业务负责人协商达成一致。
本周待办事项与应对异议
如果难以一次性迁移所有 DB，可以先选择一个依赖最少的服务，测量其恢复、验证与回滚时间，并将结果作为其他服务计划的输入依据。将负责人、迁移备选日期以及验证失败时的中止标准汇总到一份文档中，项目就能从只有时间表转变为具备可执行性的工作。
对于“当前产品开发更为紧迫”的反论，完全可以理解。但若一直保持不知道恢复方法的状态直到截止日期临近，可供选择的排查时间就会减少。本文并不宣扬特定版本的性能提升或整个社区的观点。与其关注引入最新特性的速度，本文更专注于做好应对迁移失败准备的运维建议。