根据 PostgreSQL 的版本策略，在 2019 年发布的 PostgreSQL12 将于今日（2024-11-14）正式脱离支持生命周期。PG 12最后一个小版本为 2024-08-08 发布的 12.20 ，在今天 11-14 号的例行小版本发布更新中，将不会有新的 12.21 小版本，而新发布的 PostgreSQL 17.1 则将成为当下合适的新业务选择。

PG12下台
在过去五年中，PG 12 的最后一个小版本 PostgreSQL 12.20 相对于五年前发布的 PostgreSQL 12.0 修复了 30 个安全问题，936 个 Bug。

不过，当 PG 12 过保之后，这些都不会再发生了，新出现的安全漏洞与Bug缺陷将不会有修复补丁与小版本解决。随着时间推移，运行老版本带来的风险将会持续上升， 请仍然在使用 PG 12 或更早版本的用户及时更新到受支持的大版本（13-17）

PostgreSQL 12 是五年前发布的版本，我认为是继 PG 10 之后的一个具有里程碑意义的版本。主要是 PG 12 引入了可插拔存储引擎的接口，允许第三方开发新的存储引擎。此外，还有一些重要的可观测性/易用性改进也发生在这个版本 —— 例如实时报告各种任务的进度，使用csvlog格式便于处理分析；此外，分区表也有了显著的性能改善，趋于成熟。

当然，我对 PG 12 印象比较深刻的原因是，当我做 Pigsty 这个开箱即用的 PostgreSQL 数据库发行版时，第一个公开发布支持的大版本就是 PostgreSQL 12。现在一眨眼五年过去了，当时的从 PG 11 适配 PG 12 新特性的回忆还历历在目。在这五年里，Pigsty 从一个自己用的PG监控系统/测试沙箱，变成了一个被广泛使用的开源项目，在全球社区都有了知名度。回头看看，不禁有些感慨。

PG17上位
一个版本的死去也对应着另一个版本的新生。按照 PG 版本策略，今天的例行季度小版本发布，将会发布 17.1 。我的朋友 Qunar 帅龙喜欢在 PG 新版本出来时立刻跟进升级，我自己的习惯则是在大版本出来后，额外观察等待一个小版本。因为通常来说，新的大版本发布后，大量小瑕疵小修小补都会在 x.1 中得到解决，二来三个月的缓冲区，足够让 PG 生态中的扩展插件跟进并完成适配，对新的大版本提供支持，而这对于 PG 生态用户来说是非常重要的。

从 PG 12 到现在的 PG 17，PG 社区添加了 48 项新功能特性，并提出了 130 项性能改进。特别是 PostgreSQL 17 的写入吞吐，按照官方的说法在一些场景下，相比先前版本有高达两倍的提升，还是很值得升级的。

之前我对 PostgreSQL 14 进行过一次全方位的性能评测，但那已经是三年前了，所以我准备针对最新的 PostgreSQL 17.1 重新进行一次评测。最近我整了台非常牛逼的物理机，128C 256G，配四块 3.2 T Gen4 NVMe SSD 加一块硬件 NVMe RAID 加速卡，准备看看 PostgreSQL，pgvector，以及一系列 OLAP 扩展插件能在这台性能怪兽上表现出什么样的性能，结果敬请期待。

总的来说，我认为 17.1 的推出将会是一个合适的升级时机，我也准备在未来几天里发布 Pigsty v3.1 ，在里面将 PG 17 升级为 Pigsty 默认使用的主要大版本，取代原本的 PG16。考虑到 PostgreSQL 在 10.0 之后提供了逻辑复制的功能特性，而 Pigsty 提供了使用逻辑复制进行不停机的蓝绿部署升级的完整方案 —— PG 大版本升级的难度早已今非昔比。我也将会在近期推出一个不停机大版本升级教程，帮助用户将现有的 PostgreSQL 16 或更低版本无缝升级到 PG 17

PG17扩展
让我很欣慰的一点是，相比于从 PG 15 到 PG 16 的升级，这一次 PostgreSQL 扩展生态的跟进速度相当之快，体现出了强大的活力。例如，去年 PG 16 在九月中旬发布，但是主要的扩展插件要到半年后才基本齐全 —— 比如 PG 生态的一个核心扩展 TimescaleDB 就等到二月初的 2.13 才完成 PG 16 支持， 其他的扩展也大体类似。因此在 PG 16 发布半年后，才到达了一个基本令人满意的状态。Pigsty 也是在那时将 PG 16 提升为 Pigsty 首要使用的默认大版本，替代 PG 15。

而这一次从 PG 16 到 PG 17 的替换，生态适配的速度显著加快了，三个月不到就完成了之前需要半年的活计，比 PG 15 到 16 的速度快了近一倍。在这一点上，我很自豪地说，我还做了不少工作的。比如在《PostgreSQL神功大成》中介绍过的最全扩展仓库 https://ext.pigsty.io ，我在这里维护了 PG 生态超过一半的扩展插件。

而我也是在最近刚刚完成这件大活，把维护的一百四十个多个扩展针对 PG 17 进行了构建（当然还有 Ubuntu 24.04 和部分 ARM 支持），并且自己修复或者提请扩展作者修复了几十个有兼容问题的扩展插件。目前实现的效果是：在 EL 系统上， 334 个可用扩展有 301 个已经在 PG 17 可用，而在 Debian 系统上，326 个扩展也已经有 302 个在 PG 17 上可用。

目前主要的扩展中，还有分布式扩展 Citus 和列存扩展 Hydra 缺位，图数据库扩展 AGE，PGML 也依然还没有提供 PG 17 的支持，不过其他的强力扩展目前均已实现 PG 17 Ready。

其中，特别要强调一下最近在 PG 生态如火如荼的 OLAP DuckDB 扩展缝合大赛，包括 ParadeDB 的 pg_analytics，国内个人开发者李红艳编写的 duckdb_fdw，CrunchyData 的 pg_parquet，MooncakeLab 的 pg_mooncake， Hydra 和 DuckDB 原厂 MotherDuck 亲自下场搞的 pg_duckdb，全部都已经实现了 PG 17 支持，并且在 Pigsty 扩展仓库中可用。

考虑到分布式的 Citus 用户并不多，列存 Hydra 已经有大把全新的 DuckDB 扩展可以替代，我认为 PG17 在扩展生态上已经达到了一个令人满意的状态，可以作为生产环境的首要大版本使用了。而在 PG17 上实现这一点的用时，比 PG 16 快了近一倍。