2026 年 10 月 15 日，PostgreSQL 全球开发组推出 PostgreSQL 19 的第一个候选版本 RC 1。作为一款广泛使用的开源数据库，PostgreSQL 19 的功能已经冻结，后续主要是稳定性修复；官方路线图显示 RC 2 定于 11 月 12 日，正式版 GA 计划在 11 月 19 日。对正在规划数据库升级的团队，这是一段需要开始做兼容性验证的窗口。
REPACK：在线重整表与回收空间
PostgreSQL 19 新增 REPACK 命令，用于回收磁盘空间并重整表内容，从而改善查询性能。REPACK (CONCURRENTLY) 允许在不阻塞表读写的情况下完成重整。对长期运行、频繁更新导致膨胀的表，这提供了一条比传统 VACUUM FULL 更可控的维护路径。实际使用仍要评估 I/O 开销、锁与复制延迟，尤其是高写入负载的数据库。
执行计划与优化器控制
新版本引入 pg_plan_advice 扩展，用于控制查询优化器的决策；pg_stash_advice 则根据查询自动应用计划建议。两者把“计划稳定性”从依赖统计信息与运气，变成可记录、可复用的工程手段。对曾因执行计划突变导致性能回退的系统，这类能力值得重点测试，但也要避免把建议写成永久硬编码，导致数据分布变化后无法回退。
复制与高可用
当 wal_level 设为 replica 时，逻辑复制现在可以在不重启服务器的情况下启用。逻辑复制还支持序列值复制，减少主备切换后序列冲突的手工处理。备库新增 WAIT 命令，用于实现“读己之写”一致性：应用写入主库后，可以等待备库追到指定位置再读取。对读写分离架构，这比盲目重试或强制读主更精细，但也需要评估等待超时与请求延迟。
性能与维护改进
官方列出的改进还包括：I/O 工作进程数量自动伸缩、更快的外键检查、进一步的计划与执行优化；并行 autovacuum 可对表索引并行处理，autovacuum 还引入基于评分的优先级机制。对大型数据库，这些改动会影响后台维护的时长与资源竞争，建议在预发环境用真实数据量观察 autovacuum 与 I/O 行为，而不是只看小数据集基准。
兼容性变化
升级前需要重点检查的不兼容项包括：JIT 默认改为关闭，过去依赖默认开启的大型分析查询可能需要显式启用；max_locks_per_transaction 默认值从 64 改为 128，锁容量语义随之变化；RADIUS 支持被移除；standard_conforming_strings 在服务端强制为 on；MD5 密码认证成功后会给出警告；inet/cidr 的默认索引操作类从 btree_gist 改为 GiST；MULE_INTERNAL 编码被移除。官方要求使用 pg_dumpall、pg_upgrade 或逻辑复制完成大版本迁移。
升级节奏与生态
Amazon RDS 已在数据库预览环境中提供 PostgreSQL 19 RC1，说明云厂商的验证也在同步推进。另一个时间点是：PostgreSQL 14 将在 2026 年 11 月 12 日停止接收修复，仍运行 14 的生产环境应尽快规划升级。对数据平台与后端架构团队，建议把 19 的验证拆成三轮：先跑扩展与驱动兼容，再跑复制与备份恢复，最后用真实业务查询对比执行计划与延迟。
小结
PostgreSQL 19 RC 1 于 2026 年 10 月 15 日发布，以 REPACK 并发重整、pg_plan_advice、逻辑复制免重启、WAIT 读己之写与并行 autovacuum 为看点，GA 计划 11 月 19 日，是数据库工程在可维护性与高可用性上的一次集中升级。
信息来源：PostgreSQL 官方新闻（2026-10-15）、19.0 发布说明与 PostgreSQL 19 Open Items 路线图。