PostgreSQL 14 退役倒计时：11 月 12 日之后，安全修复正式停更

PostgreSQL 的大版本支持 5 年。14.0 发布于 2021 年 9 月 30 日，5 年之期就在 2026 年 11 月 12 日——按季度发布节奏，那天的小版本（预计 14.25）就是 14 系列的最后一个版本，之后社区不再为 14 发布任何 bug 修复和安全修复。

先说结论：11 月 12 日之后，PostgreSQL 14 的每个新 CVE 都是永久无补丁。而 13 系列早在 2025 年 11 月就已经退役——如果你还在 13 上，你已经裸奔一年了。

PostgreSQL 14 退役倒计时：2026-11-12 最后一个版本

云上不会关机，但会悄悄开始收费

自建的 PG 14，11 月 12 日之后就是字面意义上的无人维护。而云上的 RDS、Azure Database、Cloud SQL 不会替你关机——它们会把掉队的实例自动转入付费的 extended support，账单开始跑。

翻译一下：原地不动，等于每个月交一笔”不升级税”。这笔钱够不够覆盖一次计划内升级的停机成本，DBA 自己算得出来。

PostgreSQL 大版本升级两条路：pg_upgrade 原地升级，或 dump/reload。pg_upgrade 允许跳过中间大版本直接升，但官方要求把中间每个大版本的 release notes 都读一遍——不兼容变更不会因为你跳过了就不存在。

目标版本四选一：15、16、17、18，社区支持分别到 2027-11 至 2030-11。选型建议：

自建 GitLab 的用户注意一个连带：GitLab 17 及更早版本绑的是 PG 14；GitLab 18 要求至少 PG 16.5，GitLab 19 最低 PG 17。应用升级会倒逼数据库升级，两件事最好一次排进同一个窗口。

1 2	-- 1. 先看自己在哪个版本 SHOW server_version;

第二步：查扩展。 PostGIS、TimescaleDB、pgvector、citus 这些扩展都有自己的大版本兼容矩阵，扩展没 ready 就升主版本，等于给自己挖坑。先去扩展的 release notes 对版本。

第三步：查逻辑复制。 有逻辑复制槽（pg_replication_slots）或发布订阅在跑的，pg_upgrade 前后要按文档处理槽和订阅，别直接升。

第四步：pg_upgrade --check 先跑一遍。 只检查不动作，把不兼容项一次性暴露出来，再决定是修还是换 dump 路线。

MariaDB 10.6（7 月已终结，最后安全版本 10.6.28）和 PostgreSQL 14（11 月 12 日退役）撞在同一个季度。如果你手里两种库都有，别分两次排期——备份窗口、业务低峰、回滚预案都是同一套，一次做完。

参考：PostgreSQL 官方 Versioning Policy；Convika《End of life in November 2026》（2026-10-23）。

原文作者: liups.com