PostgreSQL 14 将于 2026 年 11 月停止支持：升级选 17 还是 18？

生产库还在 PostgreSQL 14，升级窗口却还没排进变更日历。
最快决策：默认先评估 PostgreSQL 17；只有应用、驱动和扩展都验证通过，而且确实需要 PostgreSQL 18 的新特性时，才选 18。不要等到支持截止日再启动迁移。

适合仍运行 PostgreSQL 14、负责版本生命周期和变更审批的 DBA。
后端工程师、数据工程师与 SaaS 技术负责人，也可用本文核对扩展、停机窗口和回退方案。

最后更新于 2026 年 10 月 21 日；版本与日期核实自PostgreSQL 官方版本生命周期。截至该日，官方列出的 PostgreSQL 14 末次支持日期为 2026 年 11 月 12 日，14.24 仍在支持期内；17.11 与 18.6 是官方列出的当前小版本。此处的 17.11、18.6 是小版本，不代表 PostgreSQL 17 或 18 主版本的起始版本。

PostgreSQL 14 升级选 PostgreSQL 17 还是 18，先看支持窗口与升级节奏

官方政策为每个主版本提供 5 年支持。按生命周期页面，PostgreSQL 17 的支持窗口到 2029 年 11 月 8 日，PostgreSQL 18 到 2030 年 11 月 14 日。18 比 17 多出一年的官方维护窗口，但这并不自动意味着它更适合每个生产环境；团队是否有能力验证驱动、扩展、操作系统软件包与恢复流程，同样决定升级风险。(官方版本生命周期)

PostgreSQL 18.6 的官方发布说明列出该小版本涉及的配置、数据清理和扩展索引检查事项。版本号应在实际部署前再次确认，不能把小版本更新误写成主版本升级。

PostgreSQL 14 停止支持后，数据库会立刻不能启动吗？
停止支持不等于软件会在截止日自动停止运行，但之后不再处于官方支持周期内，不能继续依赖该版本获得常规错误修复与安全修复。若业务因变更冻结无法在截止前完成切换，应记录风险、收紧暴露面与变更权限，并由负责人明确临时例外；这不是长期替代升级的方案。

先对照兼容性，再决定是否跨到 18

PostgreSQL 18 于 2025 年 9 月 25 日发布。它包含异步 I/O 等新能力，但发布说明中的功能介绍不能代替目标业务上的性能验证。若应用的主要需求是继续获得支持、降低迁移变更范围，而现有工作负载没有明确依赖 18 的新能力，优先评估 17 通常更符合保守的生产变更路径；若 18 的功能能解决已确认的问题，则先验证，再决定是否采用。(PostgreSQL 18 发布说明)

扩展兼容性要逐项核实，不能因为某个环境装得上，就推断所有环境都兼容。至少检查以下对象：

• 数据库扩展：列出 CREATE EXTENSION 使用项、扩展版本、目标主版本的可安装包，以及扩展升级脚本；确认 C 语言扩展的二进制文件与目标服务器版本匹配。pg_upgrade 不会替团队验证所有外部模块的二进制兼容性，相关限制见官方 pg_upgrade 文档。
• 驱动与连接池：核对应用驱动、ORM、连接池和迁移工具的兼容矩阵，并在预发布环境覆盖认证、TLS、连接复用、事务与异常重连。
• 操作系统与软件包：确认新旧版本能否并行安装、扩展包从何处获取、服务单元与数据目录如何区分；不要把某个系统上的包状态当作其他系统的保证。
• 18 版迁移说明：阅读 18 的主版本迁移章节及当前小版本说明。例如 18.6 的发布说明对特定 GIN 索引和 contrib/btree_gist、contrib/ltree 提出检查事项；是否受影响要根据实际使用对象判断。

扩展兼容性应怎样核验？
先从生产库导出扩展清单，再分别核对每个扩展的目标版本包、升级脚本、系统依赖和数据兼容说明。尤其是自编译或依赖外部库的扩展，应在同一操作系统与相近配置的隔离环境做安装、升级和查询验证；没有明确兼容声明或测试结果的项目，应视为未验证，而不是默认可用。

按停机容忍度选迁移路径，不按命令名字估工期

官方提供的主版本升级路径包括逻辑转储与恢复、pg_upgrade，以及跨主版本逻辑复制。它们对停机、临时空间、操作复杂度和回退条件的要求不同；不能只看数据库大小，也不能用别人的迁移时长直接估算自己的窗口。迁移方式与准备工作可参照官方升级文档。

• pg_upgrade：适合希望复用现有数据文件、并能安排数据库停止写入的团队。先运行 pg_upgrade --check 检查条件，再在演练中记录实际停服区间；链接模式可能减少复制工作，但新集群启动后旧集群不能再作为简单的原地回退点。
• 逻辑转储与恢复：通过 pg_dump 或 pg_dumpall 导出，再恢复到目标主版本。它能提供清晰的新旧库隔离，但导出、传输、恢复和验收所需时间取决于数据量、对象数量、索引重建和实际 I/O；必须在演练中测量。
• 逻辑复制切换：可先让新主版本追平旧库，再安排切换，适用于停机容忍较低且团队有能力维护复制链路的场景。它不是免演练方案：要规划复制延迟、序列值、DDL 同步、订阅状态、切换后的写入归属和回退数据方向。

使用 pg_upgrade 的停机窗口怎么估？
没有脱离现场条件的统一时长。停机区间至少受最后一次检查、停止旧服务、实际升级操作、启动新服务和验收影响；数据目录大小、文件系统、索引与扩展状况也会改变结果。先在隔离环境用生产数据副本演练，分别记录预检查、停服、启动和业务验证时间，再以演练数据申请变更窗口。

有使用逻辑复制的团队还要单独检查槽位迁移边界：PostgreSQL 18 的升级文档指出，pg_upgrade 自动迁移逻辑复制槽的支持条件要求旧集群为 17.0 或更高版本；从 14 迁移时，不能假设旧槽位会自动带到新集群。要按实际复制拓扑设计重建、追平和切换步骤。(官方逻辑复制升级说明)

用条件分支确定目标版本

下面的决策条件应以应用负责人、DBA 和变更审批人共同确认的测试结果为依据，而不是只看新版本功能清单。

• ✅ 若扩展、驱动、连接池和系统包在 PostgreSQL 17 上验证通过，且当前没有必须依赖 18 的功能，先选 17；将较小的兼容性未知项和更保守的生产变更作为优先目标。
• ✅ 若 18 的某项能力能解决已确认的负载或应用需求，且所有关键依赖已在 18.6 或更新的目标小版本上通过测试，可选 18；按正式上线时的官方小版本重新核对迁移说明。
• ⚠️ 若扩展供应状态、驱动兼容性或恢复流程仍不清楚，不要在 17 和 18 之间凭感觉拍板；先以测试环境消除未知项。若截止时间逼近，提交变更风险和回退计划，不能把“暂时能运行”写成长期支持策略。
• ❌ 若目标版本没有可用的扩展包，或演练无法按要求恢复数据，不要直接切生产；回退到已验证的路径，或调整迁移方案后重新演练。

社区讨论可以说明管理员正在关注什么，但不能证明版本兼容性。2026 年 3 月的一则讨论涉及 PostgreSQL 14 到 18 的升级疑问；2026 年 9 月 20 日的一项项目讨论也在询问自托管 PostgreSQL 14 的支持版本和迁移方式。这些是用户关注与实操疑问的信号，不是搜索量数据，也不能代替官方文档或应用维护方的兼容声明。(社区迁移讨论)

按里程碑做演练，把恢复能力纳入放行条件

主版本升级不是替换程序文件。以下步骤可作为变更单的执行顺序，每一步都应保留负责人、产物和放行条件。

1. 盘点现状：记录 PostgreSQL 14 的小版本、操作系统、数据库与表空间、扩展、复制槽、订阅、连接入口、计划任务和监控告警。核对应用代码及驱动版本，标出需要应用维护方确认的兼容项。
2. 选择候选目标：根据前述分支确定先测试 17 还是 18。读取从 14 到目标版本之间的主版本迁移说明；官方允许跨过中间主版本，但建议阅读所跨版本的发布说明，尤其是标为迁移事项的内容。
3. 制作并验证备份：准备逻辑备份或适合现有恢复架构的备份，并将副本放在数据库主机之外。恢复到隔离环境，验证库、角色、权限、扩展、序列和关键业务查询；只确认“备份文件生成成功”不算完成恢复验证。官方列出了 SQL 转储、文件系统备份和连续归档等不同备份方式，各自有适用条件。(官方备份与恢复文档)
4. 搭建演练环境：尽可能使用接近生产的操作系统包、扩展版本、配置与数据副本，执行目标迁移路径。对 pg_upgrade 先运行预检查；对逻辑复制记录同步延迟与槽位处理方式；对转储恢复记录导出、恢复、索引重建和校验各阶段耗时。
5. 做应用与数据验收：覆盖登录、读写、事务、关键查询、计划任务、连接池重连、扩展函数、备份和恢复。对关键查询比较执行计划及业务结果，不把主版本发布说明中的性能描述当作本库的实测结论。
6. 定切换与回退条件：写清停止写入的时点、DNS 或连接配置切换责任、数据一致性检查、观察指标和停止条件。明确新库开始接收写入后，旧库如何处理；不能把“重新启动旧实例”当作所有迁移方式都适用的回滚方案。
7. 安排变更与复核：留出回滚决策窗口，变更后检查错误日志、复制状态、备份任务和业务指标。目标小版本发布或依赖包变化时，重新审阅相应说明，不沿用过期的验证结论。

迁移主机的资源与数据保护也要一起定案

迁移过程可能短时同时保留旧数据、新数据、转储文件、索引重建空间和备份暂存空间；因此容量核对要按数据目录、表空间、WAL、临时文件和保留策略分别估算，并用演练结果修正。内存规划也应覆盖数据库、连接池、监控和迁移任务的峰值占用，不要把物理内存全部视作数据库缓存。

若迁移计划包含换到独享服务器，可先核对 CloudUDP 当前可选配置与月租项目：页面列出 128GB 或 256GB ECC 内存、标配 2 × 1TB 直连 NVMe，并可选增加 NVMe；硬盘为独立直连、无硬件 RAID。选型时要按镜像后的可用容量重新核算，并自行规划软 RAID、复制或其他冗余方式；这些都不能替代机外备份。配置和价格以该页面当前产品表为准。

如果数据库必须在迁移后持续服务，还要分别规划主机故障、磁盘故障和误操作的应对方式。双盘直连不等于 RAID-1；若选择软 RAID 或复制，应通过故障演练确认恢复流程，而不是只在配置文件里看到“冗余”字样。备份副本需放在主机之外，并定期实际恢复。Linux 登录方式与首次接入细节可对照 SSH 接入说明。

PostgreSQL 14 的支持截止日期是 2026 年 11 月 12 日，目标版本则应由兼容性盘点、停机演练和恢复验证共同决定。若目前运行在共享云实例，CPU 争抢或规格限制可能让资源表现不稳定，云盘 IOPS 与吞吐也可能按档计费；若长期需要固定的独享算力、可自行安排 NVMe 盘布局和系统，迁移到独享 AMD 物理服务器可以纳入方案比较。CloudUDP 页面列有实际可选的内存、直连 NVMe 与系统项目；先完成迁移验收和数据保护设计，再按产品表核对是否匹配目标库的容量与运行方式。