PostgreSQL 18 落地现状:托管平台支持、扩展兼容与升级窗口

更新日期：2026-10-05

PostgreSQL 18 发布于 2025 年 9 月 25 日,到现在已经一岁:当前小版本 18.6(2026-08-13),四大托管平台全部支持,RDS 上的标准支持期排到 2031 年。「要不要升 18」这个问题的答案在 2026 年秋天已经没有悬念——真正把决策推到眼前的是另外两件事:PostgreSQL 14 将于 2026-11-12 停止支持(还有一个月出头),一批团队被迫在这个季度完成跨版本迁移;而 18 的 pg_upgrade 在统计信息保留与并行检查上的改进,让「跨版本升级」的实际成本比 17 时代明显降低。

本文按「落地现状」组织:18 的能力哪些在生产里真实可用、四大托管平台的支持进度、升级窗口里的三个新变化与不兼容清单、三条升级路线的取舍,以及给不同起点团队(14/15/16/17)的决策建议。迁移的操作细节与停机规划,站内 PostgreSQL 14 EOL 迁移指南:升级到 17/18 的停机、验证与回滚 已经完整写过,本文不重复,只补 18 特有的增量。

适用范围:自建或托管在 RDS/Aurora/Cloud SQL/Azure 上的 PostgreSQL 14–17 生产库。不适用场景:还在 13 或更早的——官方版本策略表里 PG 13 已停止支持,你的问题不是「18 还是 17」而是「立刻启动迁移」;强依赖尚未适配 18 的扩展的团队——第四节的不兼容清单就是为你准备的评估入口;以及期待「升级即提速 3 倍」的读者——官方口径是异步 I/O 在特定场景下读性能最高提升 3 倍,收益分布极不均匀,按自己的负载实测。

先看结论

1. 平台支持已经齐了:RDS for PostgreSQL 18 于 2025-11-13/14 GA(标准支持到 2031-02-28);Aurora PostgreSQL 18 于 2026-02-26 GA(18.3+);Cloud SQL 于 2025-11-20 GA;Azure Flexible Server 支持 18。托管用户没有「平台不支持」的借口了。
2. 当前小版本是 18.6(2026-08-13)——注意 18.5 因回归问题被官方跳过未发布,如果内部文档里写着「等 18.5」,把它划掉。
3. 18 的旗舰能力是异步 I/O 子系统(io_method = worker / io_uring / sync),顺序扫描、bitmap heap 扫描与 vacuum 受益;收益集中在 IO 等待型负载,重计算/网络型负载感知有限。
4. 升级体验是隐性大版本:pg_upgrade 保留大部分 planner 统计信息、支持 --jobs 并行检查与 --swap,升级后不再需要漫长的统计重收集——跨版本升级的停机窗口实际缩短。
5. 一个必须提前核对的坑:18 起 initdb 默认启用数据校验和(data checksums),pg_upgrade 要求新旧集群的 checksum 设置一致——老集群没开 checksum 的,要么先补开,要么在新集群显式 --no-data-checksums。
6. md5 密码认证在 18 里被弃用,迁移窗口顺手切 SCRAM;非 libc 排序规则提供者(ICU/builtin)的集群,升级后要重建全部全文检索与 pg_trgm 索引。
7. PG 14 的死线是 2026-11-12:官方版本策略表明文,没剩多少缓冲。14 的团队目标直接定 18(不必先到 17),用逻辑复制路线可以做到秒级切换。
8. PG 19 还在 Beta(Beta 4 于 2026-09-24 发布,即将进 RC),且 Beta 4 回滚了 SQL/PGQ、在线开关 checksum 等多项特性——「等 19」不构成推迟 18 的理由。

18 的真实卖点:异步 I/O 与升级体验

官方发布公告的能力清单里,生产团队真正能感知的是三层:

异步 I/O 要按「子系统默认值变化」来对待:升级后 io_method 的默认与最佳值取决于内核版本与负载形态,io_uring 需要新内核与容器环境里的相应支持——先在预生产用真实负载对比 worker/io_uring/sync 三档再定,不要沿用社区口径直接切。逻辑复制侧的改进(冲突记录、CREATE SUBSCRIPTION 默认并行流、空闲复制槽自动删除、pg_createsubscriber --all)让「逻辑复制升级路线」的运维成本进一步下降,这对下一节的路线选择有直接影响。

托管平台支持现状(截至 2026-10-05)

四大平台的官方口径:

自建侧,社区当前小版本即 18.6(18.5 被官方跳过)。云上升级的一个重要差异:托管平台的大版本升级用厂商工具(RDS 的 major version upgrade、Cloud SQL 的原地升级),本文后文的 pg_upgrade 操作仅适用于自建;云用户要核对的是厂商工具与 18 的新特性(checksums 默认、ICU 排序规则)的交互行为,以厂商文档为准。

升级窗口:pg_upgrade 的三个新变化

自建用户的升级体验在 18 有实质改善,三件事改变了窗口的实际形态:

统计信息随升级保留。 18 的 pg_upgrade 迁移大部分优化器统计(扩展统计与 CREATE STATISTICS 除外),意味着升级完成后查询计划直接是「热的」——不再有旧版升级后业务抖动几小时、等 ANALYZE 慢慢收敛的经典桥段。残余缺口的官方补法:

# 升级后只补缺失统计(不再全量 ANALYZE)
vacuumdb --all --analyze-in-stages --missing-stats-only

并行检查与 --swap。 pg_upgrade --jobs N 并行化检查与迁移环节,--swap 优化目录切换。大库的窗口估算要按新参数重新做——还在用两年前的「升级要停 4 小时」经验值的团队,先在预生产用真实数据量实测一遍,窗口可能已经缩短一半以上。

checksum 一致性要求(最重要的新前置)。 18 起 initdb 默认启用数据校验和,而 pg_upgrade 要求新旧集群 checksum 设置匹配。老集群(17 及以前默认不开)直接用默认参数 initdb 出来的 18 新集群会在升级检查时被拒:

# 升级前核对新旧两侧的 checksum 状态
pg_controldata "$OLD_PGDATA" | grep -i checksums
pg_controldata "$NEW_PGDATA" | grep -i checksums
# 不匹配时二选一:老库先开 checksum(pg_checksums --enable,需停机)
# 或新集群 initdb 时显式 --no-data-checksums(不推荐长期,checksum 建议 19 前找窗口补)

checksum 本身值得开(静默数据损坏的早发现),正确的姿势是把「补开 checksum」作为升级项目的第一阶段,而不是用 --no-data-checksums 永久绕开。

升级前的不兼容与行为变更清单

官方 Release Notes 的 Migration to Version 18 章节里,生产影响最大的几条:

• md5 密码认证弃用:迁移窗口切 SCRAM-SHA-256,顺带核掉应用连接串里的老认证方式。
• 全文检索与 pg_trgm 索引重建:FTS 改用集群默认排序规则提供者——非 libc(ICU/builtin)的集群,pg_upgrade 后应重建全部 FTS 与 pg_trgm 索引,否则排序相关行为可能不对。升级脚本里给这类索引预留重建时间:

-- 找出需要重建的索引(升级后在维护窗口执行 REINDEX)
SELECT indexrelid::regclass
FROM pg_index
JOIN pg_class c ON c.oid = indexrelid
WHERE c.relam = 0;   -- 实际清单以官方迁移章节的判定方法为准,先在预生产演练

• 扩展共享库必须在升级前装进新集群(pg_upgrade 不会重建 schema,但缺共享库会直接失败):把 pg_available_extensions 的核对列入升级前检查,时间线敏感的扩展(PostGIS、pgvector 等)先确认 18 兼容版本。
• reg OID 引用类型列不支持 pg_upgrade*(regcollation 等):命中即改用逻辑复制路线或先做类型改造。
• 其余行为变更(时区缩写、VACUUM/ANALYZE 的 ONLY 语义、COPY CSV 对 '\.' 的处理、禁用 unlogged 分区表、AFTER trigger 角色语义)逐条过一遍官方迁移章节,大部分团队不会被击中,但每一条都符合「三天后才发现」的事故画像。

三条路线怎么选:停机预算决定一切

决策规则很朴素:停机预算是唯一输入。能容忍小时级窗口的小中型库,pay_upgrade 是性价比之王;窗口敏感的核心库,逻辑复制路线(站点内 PG 14 迁移文的主线方法)在 18 时代成本更低了。两条路线共同的底线:升级前 72 小时内完成一次全量恢复演练,这一条在任何版本间迁移都成立,18 不是例外。

不同起点的决策建议

• PG 14(死线 2026-11-12):没有第二选项,本季度动。目标直接定 18(官方支持跨版本直升,逻辑复制路线不要求逐级);方法照站内 14 迁移文执行,本文的不兼容清单作为 18 特有增量合并进检查表。资源紧张的团队,把 checksum 补开与 md5→SCRAM 提前做,这两个动作独立于升级本身,做了就赚。
• PG 15/16:窗口宽松,建议避开业务高峰排在未来两个季度;目标 18,路线按停机预算选。
• PG 17:不着急,但把 18 的增量(异步 I/O 调优、skip scan 收益、temporal 约束需求)纳入技术债清单,选一个常规维护窗口完成;checksum 如果 17 上还没开,先补开,给未来的 pg_upgrade 扫清前置。
• 全新项目:直接 18,uuidv7()、virtual generated columns、temporal 约束都值得在建模时用上;io_method 用默认起步,有实测依据再调。

验证清单

• 新旧集群 checksum 状态已核对并达成一致(或已完成补开计划)。
• 扩展清单核对完成:新集群已装齐全部共享库,时间线敏感扩展确认 18 兼容版本。
• 全文检索与 pg_trgm 索引的重建脚本已在预生产演练,耗时已计入窗口。
• md5→SCRAM 迁移完成,应用连接串无 md5 认证残留。
• pg_upgrade 用 --jobs 在预生产跑过全量演练,窗口实测值写入变更单。
• 升级后执行 vacuumdb --all --analyze-in-stages --missing-stats-only,核心查询的执行计划抽查正常。
• io_method 三档在预生产的对比数据留档,生产值有明确依据。
• 回滚路径演练过:pg_upgrade 路线 = 备份恢复,逻辑复制路线 = 反向切流。
• 托管用户:厂商升级工具与 18 新特性的交互已核对,扩展限制清单已过目。

异步 I/O 调优起点与测量方法

io_method 的三档选择不该靠口碑,该靠 pg_stat_io 的实测。升级后的调优流程:

-- 1. 确认当前 I/O 方法
SHOW io_method;

-- 2. 观察真实 I/O 行为:reads/hits/writes 按后端类型分布
SELECT backend_type, object, context,
       sum(reads) AS reads, sum(hits) AS hits,
       sum(read_time) AS read_ms, sum(write_time) AS write_ms
FROM pg_stat_io
GROUP BY 1,2,3
ORDER BY reads DESC
LIMIT 15;

-- 3. 缓存命中之外的关键口径:rereads(缓存未命中后的再次读)
SELECT sum(reads) AS total_reads, sum(hits) AS hits,
       round(100.0*sum(hits)/nullif(sum(hits)+sum(reads),0), 2) AS hit_ratio
FROM pg_stat_io;

三档的适用画像:sync 是旧行为(不受益);worker 是默认安全档(后台 worker 执行预读);io_uring 延迟最低但要求新内核(Linux 5.1+ 的 io_uring 支持)且容器环境需确认 seccomp 放行。调优顺序:先在 worker 档跑基准留档 → 切 io_uring 对比 → 收益不显著就回 worker。判断依据用你业务的真实慢查询清单,不要用通用基准工具——异步 I/O 的收益集中在顺序扫描与 bitmap heap 扫描,你的负载里这两类访问占比决定了收益上限。

容器/K8s 用户再记一条:io_uring 在容器里的可用性取决于运行时的 seccomp profile 与设备暴露,docker 默认 profile 曾经拦截 io_uring 系统调用——切档前先在目标运行环境里做一次系统调用级的验证,别把「宿主机支持」当成「容器里可用」。

升级后的第一周观察清单

迁移完成的判定不是「切流成功」,而是第一个业务周期无异常。升级后第一周的观察点,按优先级:

计划质量:统计信息保留让 18 的升级后计划通常是热的,但少数依赖扩展统计的查询会例外——每天跑一次慢查询 Top 20 对比升级前基线,三天无恶化即视为通过。

I/O 行为:io_method 切换后的物理读写模式变化需要 3–5 天才能看出趋势,观察 pg_stat_io 的 rereads 与 read_time 周环比;vacuum 的行为变化(异步 I/O 受益方)在表膨胀明显的库上第一个 autovacuum 周期才体现。

复制与备份:升级后第一次全量备份 + 恢复演练完成前,「升级完成」四个字不能写进变更单;流复制的延迟基线重新采集(大版本升级后 WAL 量可能有变化)。

扩展行为:时间线敏感的扩展(PostGIS、pgvector、pg_trgm)在真实负载下跑一遍核心操作——预生产的回归覆盖不到的数据形态,第一周的真实流量会补上。

# pg_upgrade 演练骨架(预生产,以官方文档参数为准)
pg_upgrade   --old-bindir /usr/lib/postgresql/17/bin   --new-bindir /usr/lib/postgresql/18/bin   --old-datadir /var/lib/postgresql/17/main   --new-datadir /var/lib/postgresql/18/main   --jobs 4 --link --check          # 先 --check 演练,确认后再正式执行

官方资料与继续阅读

外部官方链接:

• PostgreSQL 18 发布公告(2025-09-25):https://www.postgresql.org/about/news/postgresql-18-released-3142/
• 官方版本策略与 EOL 表:https://www.postgresql.org/support/versioning/
• Release 18 迁移注意事项(Migration to Version 18):https://www.postgresql.org/docs/18/release-18.html
• pg_upgrade 官方文档:https://www.postgresql.org/docs/18/pgupgrade.html
• PG 19 Beta 4 公告(2026-09-24):https://www.postgresql.org/about/news/postgresql-19-beta-4-released-3386/
• RDS for PostgreSQL 版本日历:https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-release-calendar.html
• Aurora PostgreSQL 版本日历:https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/aurorapostgresql-release-calendar.html
• Azure Database for PostgreSQL 支持版本:https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-supported-versions

站内相关文章:

• PostgreSQL 14 EOL 迁移指南:升级到 17/18 的停机、验证与回滚——迁移操作与停机规划的完整前置篇
• MySQL 8.0 EOL 之后的路线:留在 8.4 LTS 还是评估 9.x——另一条数据库线的平行决策
• Cloudmonitor 与机器人告警——升级窗口的监控与告警配套

事实与日期边界:本文版本号、GA 日期、特性与不兼容清单截至 2026-10-05,来自 PostgreSQL 官方文档与各云厂商官方发布日历;PG 19 的特性集合在 Beta 阶段仍可能变动;云厂商的扩展支持清单与升级工具行为以其官方文档当日版本为准。