PostgreSQL 19 的正式版计划于 2026 年 11 月 19 日发布，目前处于 RC 1 阶段。下一步计划是在 11 月 12 日发布 RC 2；如果测试发现需要延期的问题，也可能调整正式版日期。

一、PostgreSQL 19 从 Beta 到 GA，走到了哪一步？

PostgreSQL 19 已完成四轮 Beta 测试，并进入发布候选阶段。各阶段的发布记录见官方项目新闻归档，后续安排见PostgreSQL 19 Open Items。

Beta 编号不能用来推算距离正式发布还有几天。Beta 4 之后可能安排多轮 RC，RC 1 发布后也没有固定的一周等待期。是否继续增加候选版，取决于测试结果和问题修复进展。

二、Beta、RC 和 GA 分别意味着什么？

Beta 是公开测试阶段。按照官方 Beta Information的说明，此时已冻结新功能的加入，重点转向测试、兼容性验证和问题修复。不过，已加入的功能仍可能调整，甚至被移除。

RC 是发布候选阶段。这一阶段的版本与初始正式版已较为接近，但仍处于预发布状态。测试中出现问题时，团队还会修复并视情况推出下一轮 RC。Beta 和 RC 都不适合直接用于生产系统。

GA 是正式公开发布。判断是否达到这一阶段，要看正式发布公告，不能只看版本名称里出现了“19”。即使上游已经 GA，实际部署前仍要确认扩展、驱动、备份工具和应用是否完成兼容性验证。

三、为什么有的页面还写 10 月发布？

官方 Roadmap 的“Next major release”部分仍写着计划于 2026 年 10 月发布 PostgreSQL 19；而 10 月 15 日的 RC 1 公告已经给出 11 月 19 日这一更具体的 GA 计划。

根据 RC 1 公告，11 月 12 日受支持版本更新所包含的一批修复，也将加入 PostgreSQL 19。团队因此安排先发布 RC 2，再发布 GA。理解发布时间时，应以这项具体安排为依据，并将正式版日期表述为计划日期。

早期 Beta 阶段的预计窗口也不能一直沿用。例如，Beta 1 公告曾预计在 2026 年 9 月或 10 月完成最终发布。这个窗口反映的是当时的安排，不能覆盖后续公告中的新计划。

四、怎样查到准确的发布状态？

1. 先看官方项目新闻，确认“已经发布了什么”

打开PostgreSQL 项目新闻归档，找到日期最新、与 PostgreSQL 19 相关的发布公告。先看标题是否带有 Beta 或 RC，再看正文是否明确宣布正式发布。

接着查看公告的“Release Schedule”部分。“planned”“should”“unless an issue is discovered”等用语说明日期仍附有条件。即便已经到了计划发布当天，只要正式发布公告尚未出现，就不能直接判断为已 GA。

2. 再看 Beta Information，确认当前预发布版本

Beta Information会列出当前预发布版本。目前该页列出的版本是 PostgreSQL 19 RC 1。页面名称中虽然有 Beta，也会展示 RC，因此应以正文里的具体版本为准。

3. 用 Open Items 了解进度，不自行推算发布日期

PostgreSQL 19 Open Items列出重要日期，以及尚未解决和已经解决的问题。它适合用来理解发布前还有哪些工作，但问题数量与发布时间没有简单的换算关系。某项问题已修复，也不等于包含该修复的安装包已经发布。

4. 用版本支持表交叉核对正式发布记录

Versioning Policy中的版本表包含主版本、当前小版本和首次发布日期，可作为正式发布后的交叉核对来源。不同页面的更新进度可能有差异，此时需要结合最新的具体发布公告判断，不能仅依赖某一张版本列表。

五、怎样确认自己连接的数据库是不是正式版？

确认官网发布进度后，还需要单独检查实际数据库实例。连接目标数据库，执行下面的只读 SQL 即可查看服务端版本：

其中，server_version用于查看服务端版本文字，version()还会提供构建等信息。版本信息函数的说明见官方文档。

上表展示的是版本号的识别方式。server_version_num适合程序做版本比较，但不宜单独用来区分 Beta、RC 和 GA；判断预发布阶段时，应一起查看文字版本。

在终端中也能完成查询。先把示例里的主机、端口、用户名和数据库名换成实际连接信息，再执行命令：

不要用 psql --version代替服务端查询：它显示的是本机 psql 客户端版本。机器上装了新版客户端，远端数据库仍可能运行旧版。相关选项可查阅psql 官方文档。

云数据库用户还需查看服务商的引擎版本说明，并确认所在区域是否已经开放。PostgreSQL 上游正式发布，与云平台提供该版本并不是同一个时间节点。

六、等待正式版期间，升级工作怎么安排？

等待正式版期间，可以先建立独立测试环境，检查常用业务查询、扩展、驱动、备份恢复流程和升级耗时，同时记录候选版编号。后续 RC 或 GA 到来后，再根据版本变化重复相关验证。

从较早主版本迁移到 PostgreSQL 19，需要按主版本升级处理。官方版本策略说明，通常需要使用 pg_upgrade或导出、恢复数据；具体步骤应以目标版本的升级文档与发布说明为准。测试版之间的迁移也应阅读各自公告，不能假定替换程序文件就能完成升级。

接下来的计划节点分别是 11 月 12 日发布 RC 2、11 月 19 日发布 GA。安排正式部署时，应先确认正式版公告，再完成所用扩展与应用的升级验证。