PostgreSQL 19：新功能、发布时间与 18 升级 19 指南
PostgreSQL 19 Beta 2 新功能、发布时间与 PostgreSQL 18 升级 19 清单，覆盖兼容性、pg_upgrade、扩展、回滚与生产风险
截至 2026-08-02，PostgreSQL 19 的最新公开测试版是 Beta 2，还不是正式生产版本。PostgreSQL 官方路线图计划在 2026 年 9 月发布 19；Beta 2 公告使用了更保守的 2026 年 9–10 月窗口。最终日期、功能细节和兼容性要求仍可能变化。
现在不要把 PostgreSQL 19 Beta 用于生产
官方鼓励用真实工作负载测试 Beta，但明确不建议运行在生产环境。本页适合提前评估、建立兼容矩阵和演练 PostgreSQL 18 升级 19；正式切换应等待 GA、目标 minor、扩展和托管平台支持。
PostgreSQL 19 最新消息与发布时间
| 日期 | 官方进展 | 对使用者的意义 |
|---|---|---|
| 2026-06-04 | PostgreSQL 19 Beta 1 发布 | 功能预览开放，适合开始 CI 与应用兼容测试 |
| 2026-07-16 | PostgreSQL 19 Beta 2 发布 | 修复 Beta 1 回归，并继续调整 temporal、SQL/PGQ、逻辑解码和 autovacuum 等实现 |
| 2026-09（计划） | 官方路线图的目标月份 | 不是不可变承诺；Beta 公告保留 9–10 月发布窗口 |
Beta 2 仍允许数据库行为、API 和功能细节发生小幅变化。跟踪时以 PostgreSQL 19 Release Notes 和官方新闻为准，不以第三方功能清单作为上线依据。
PostgreSQL 19 Linux 软件包可用性
软件包快照证据 · PkgSeek
发行版官方仓库：postgresql-19
PkgSeek 没有为这个坐标返回准确匹配。这只表示“当前快照未收录”，不等于“软件包不存在”；执行操作前仍需核对上游仓库。
软件包快照证据 · PkgSeek
PGDG 仓库：postgresql-19
PkgSeek 没有为这个坐标返回准确匹配。这只表示“当前快照未收录”，不等于“软件包不存在”；执行操作前仍需核对上游仓库。
这两个快照用于追踪正式软件包落地情况，不是 PostgreSQL 19 的发布状态来源。Beta tarball、开发构建或容器存在，不代表发行版仓库已经提供可用于生产升级的 postgresql-19。进入 GA 后仍应等待目标操作系统、CPU 架构、扩展和备份工具形成完整兼容矩阵。
PostgreSQL 19 有哪些新功能
下面是截至本页核对日最值得工程团队测试的方向，不代表最终发布说明的完整摘要。
SQL、图查询与时间数据
- SQL/PGQ Property Graph Queries：在关系数据上定义并查询 property graph；应验证驱动、SQL parser、ORM 和 AI SQL 生成器是否认识新语法。
FOR PORTION OF：让UPDATE、DELETE针对时间范围操作，适合测试 temporal 数据模型，但 Beta 2 仍修复了多项相关问题。GROUP BY ALL：自动对 target list 中非 aggregate、非 window 项分组。- Window functions
IGNORE NULLS/RESPECT NULLS：适用于lead()、lag()、first_value()、last_value()和nth_value()。 INSERT ... ON CONFLICT DO SELECT ... RETURNING：可返回发生冲突的行，并选择性加锁。
运维、性能与可观测性
REPACK与REPACK CONCURRENTLY：统一VACUUM FULL/CLUSTER的重写能力，并提供降低排他锁影响的新路径；旧命令为兼容仍保留。- 分区拆分与合并：新增
ALTER TABLE ... SPLIT/MERGE PARTITIONS。 - 并行 autovacuum worker，以及
pg_stat_autovacuum_scores、pg_stat_lock、pg_stat_recovery等观测视图。 - 异步 I/O read-ahead、
COPY FROMSIMD、radix sort、外键检查等性能改进。 EXPLAIN ANALYZE新增IO选项；EXPLAIN (ANALYZE, WAL)可报告 full-page write bytes。- 新数据默认 TOAST 压缩从
pglz改为lz4。
核心 REPACK 不等于 pg_repack 扩展
PostgreSQL 19 的 REPACK (CONCURRENTLY) 是基于 logical decoding 的核心 SQL command，对 replica identity、unlogged/partitioned/system table、replication slot 和额外磁盘有约束；第三方 pg_repack 是独立 extension 与 CLI。两者不能共享未经验证的运行手册。参见 扩展生态选型 与 PostgreSQL 19 REPACK 文档。
为 AI / Agent 标记版本边界
如果 Agent 的目标实例还是 PostgreSQL 18，不要让它生成 SQL/PGQ、FOR PORTION OF、GROUP BY ALL 等 19 才有的语法。把 server_version_num、允许语法和扩展版本写进检索上下文或工具契约。
PostgreSQL 18 升级 19：需要注意什么
PostgreSQL 18 → 19 是 major upgrade，不能把 18 的 data directory 直接交给 19 启动。可选路径是 pg_upgrade、逻辑 dump/restore 或逻辑复制。升级前优先处理以下兼容性变化。
1. 认证与安全变化
- RADIUS 支持被移除；仍依赖 RADIUS 的环境必须先设计替代认证路径。
- PostgreSQL 18 已把 MD5 密码标记为 deprecated；19 会在 MD5 认证成功后发出 warning。迁移计划应推进 SCRAM，而不是只屏蔽 warning。
- 新增密码即将过期 warning，默认阈值为 7 天；检查监控是否会把预期 warning 当故障。
2. SQL 与对象兼容性
standard_conforming_strings在服务器端强制为on。如果旧环境曾设为off，使用 19 版pg_dump/pg_dumpall重新导出，或先修正设置与应用转义行为。- database、role、tablespace 名称不能包含 CR/LF；
pg_upgrade会拒绝此类 cluster。 - 使用
btree_gist的inet/cidrindex 会阻塞pg_upgrade，因为旧 opclass 可能漏行；让pg_upgrade --check给出实际阻塞项，再按 release notes 处理。 MULE_INTERNALencoding 被移除，相关数据库必须以其他 encoding dump/restore。
3. 默认值、性能与监控变化
- JIT 默认关闭。大型分析查询不能假设升级后计划行为不变；分别在
jit=off/on下记录执行时间和计划。 max_locks_per_transaction默认值从 64 变为 128，同时锁内存计算发生变化；不要只复制旧配置数字，应重新做容量评估。pg_stat_subscription_stats.sync_error_count更名为sync_table_error_count；等待事件类型BUFFERPIN更名为BUFFER。修正 dashboard、告警和采集 SQL。- 新默认只影响新写入数据，不代表升级后所有旧 TOAST 值会自动改用 LZ4；不要把默认变化等同于无条件压缩收益。
4. 扩展、驱动与平台
pg_upgrade 可以检查核心 cluster 的许多二进制条件，但不能证明第三方 module 与 PostgreSQL 19 二进制兼容。为 PostGIS、pgvector、TimescaleDB、自定义 C extension、审计插件、备份代理、pooler、ORM 和驱动分别记录：
| 组件 | 需要确认 |
|---|---|
| Extension | 19 对应 package/shared library、支持声明、升级脚本、index 重建要求 |
| 驱动与 ORM | server version detection、19 新/变更语法、prepared statement、类型映射 |
| 连接池 | startup parameter、认证、failover 与连接回收行为 |
| 备份与 CDC | 新版本 catalog、WAL/逻辑解码、restore 演练 |
| 云数据库 | 区域、SKU、扩展版本、升级窗口与回退能力；以服务商上线公告为准 |
PostgreSQL 18 升级 19 实战清单
阶段 A：现在就可以做
- 固定一份 PostgreSQL 18 生产备份并完成 restore 验证。
- 清点 extension、collation、replication slot、tablespace、自定义 full-text 文件、认证方式和外部 module。
- 用 PostgreSQL 19 Beta 2 建立可丢弃的测试环境，运行 migration、应用测试、备份恢复、CDC 和关键查询 benchmark。
- 对比
EXPLAIN (ANALYZE, BUFFERS, WAL)；单独评估 JIT 默认变化与新 I/O 行为。 - 在 CI 中禁止把 PostgreSQL 19 专属语法下发给 18 实例。
把 PostgreSQL 18.4 设为阻断发布的生产门禁，把 PostgreSQL 19 Beta 2 设为前瞻兼容通道；后者可以先允许失败，但每个失败都应归类并在 GA 采用前清零。完整流水线见 PostgreSQL 安全迁移与零停机 Schema 变更。
阶段 B：正式切换前
先运行 19 版 pg_upgrade 的只检查模式；路径必须替换为目标环境实际目录：
/opt/postgresql/19/bin/pg_upgrade \
--old-bindir=/opt/postgresql/18/bin \
--new-bindir=/opt/postgresql/19/bin \
--old-datadir=/data/postgresql/18 \
--new-datadir=/data/postgresql/19 \
--check--check 不迁移数据，但应使用与正式切换相同的 binary、extension、initdb 参数和 transfer mode 做演练。不要把示例路径直接复制到生产。
然后完成：
- 锁定 PostgreSQL 19 正式 minor、OS package、container digest 与 extension 版本；
- 根据数据量选择
pg_upgradecopy/clone/link/swap、dump/restore 或逻辑复制； - 记录预计停机、额外磁盘、统计恢复时间、DNS/连接池收敛时间；
- 定义 rollback 判据、负责人和最晚回退时点；
- 验证 standby、slot、sequence、large object、权限、RLS、job scheduler 和备份链路。
阶段 C：切换后
- 执行
pg_upgrade生成的 post-upgrade / rebuild 脚本，完成前不要访问被标记的表。 - 按工具提示补齐 optimizer statistics；再比较高流量查询的计划与延迟。
- 检查错误率、认证 warning、复制 lag、WAL、autovacuum、锁和备份。
- 进行一次从 PostgreSQL 19 新备份恢复的演练。
- 只有通过业务验收且回退窗口关闭后，才清理 PostgreSQL 18 cluster。
完整步骤见 PostgreSQL 19 pg_upgrade；复制与切换原则见 复制、故障切换与升级。
PostgreSQL 19 常见问题
PostgreSQL 19 正式版发布了吗？
没有。截至 2026-08-02 最新版本是 Beta 2。官方路线图目标是 2026 年 9 月，Beta 公告给出的窗口是 9–10 月；最终以 PostgreSQL 官方新闻为准。
PostgreSQL 18 能直接升级到 PostgreSQL 19 吗？
可以按 major upgrade 路径直接迁移，不要求先经过其他 major。常见方法是 pg_upgrade、dump/restore 或逻辑复制；Beta 只用于演练，生产升级应等待正式版和依赖支持。
PostgreSQL 18 升级 19 会停机多久？
没有通用数字。停机由数据量、relation 数量、transfer mode、extension/reindex、统计恢复、连接切换和验证决定。必须在恢复出的真实数据副本上演练并测量。
云 PostgreSQL 什么时候支持 19？
不同厂商、区域和 SKU 的节奏不同。不要从社区 GA 日期推导云平台可用日期；跟踪服务商官方版本矩阵，并核对 extension、PITR、read replica 和回退限制。参见 云 PostgreSQL 选型。
现在应该从 PostgreSQL 18 升级 19 吗？
现在适合建立测试矩阵，不适合把 Beta 作为生产默认。正式版发布后，也应先等待自己依赖的扩展、驱动、工具和托管平台给出明确支持，再根据业务收益与风险排期。
事实状态与复核
本页状态快照：PostgreSQL 19 Beta 2，核对日期 2026-08-02。进入 RC、GA 或 release notes 发生重要兼容性变化时，应更新标题说明、新闻时间线、升级阻塞项和 updatedAt。
Last updated on