云数据库何时能用PostgreSQL 19？预览与正式升级怎么分

厂商不会都在社区发布后同一天开放19。预览可用、新建正式实例、已有库升级，以及特定区域规格开放，往往需要分别确认。

2026年11月2日社区19仍为RC，GA计划在11月19日。云端出现19试用入口，并不能直接证明已正式开放生产支持。

一、先分清四种“已经支持”

兼容PostgreSQL协议的产品，也不一定实际运行社区19。带专门引擎或兼容实现的服务，需要按自己的版本和功能文档判断。

二、几家服务商目前能确认什么？

Amazon RDS 在 2026 年 6 月 8 日宣布，19 Beta 1 已进入 Database Preview Environment。这个消息证明提供过预览测试环境，不代表 RDS 生产实例已经开放 19。该预览环境还有生命周期、备份使用范围等限制，不能当作长期生产库。

Azure Database for PostgreSQL 的支持版本页面目前列到 18，不能据此写出 19 的具体正式开放日期。Google Cloud SQL 的版本表也列到 18；其版本政策写明，新主版本通常在社区 GA 后 90 天内支持，但政策窗口并不是某个区域、某个升级操作的具体发布日期。

其他厂商同样应看对应产品的公告、版本表和控制台。没有明确承诺的日期，就不要替厂商推算“某月某日一定能升”。

三、自建为什么能早一点，托管为什么还要等？

自建环境可以自行选择程序包或编译版本，安排测试也比较自由。但备份、高可用、扩展适配和故障处理，都由自己负责。装得早不等于已经适合业务。

托管服务还要把新版本与自动备份、恢复、主备切换、监控、参数管理及扩展白名单结合起来。即使社区命令已经存在，托管账号也未必有权限执行，服务商也可能限制某些参数。

因此，不要仅仅因为版本号一样，就认为自建测试结果可以原样套到云实例。至少还要在实际托管环境完成一次验证。

四、云上确认能不能升，按这个顺序查

1. 确认产品名称，分清普通托管 PostgreSQL 与其他兼容引擎。
2. 查看正式版本说明，区分预览和生产支持。
3. 在目标区域确认实例规格、新建版本和已有实例升级入口。
4. 核对应用需要的扩展、参数和维护命令权限。
5. 用测试实例演练备份恢复、升级和切换，再安排生产时间。

若控制台只允许新建 19，旧实例没有相应升级入口，就要进一步确认是尚未开放，还是需要特定中间版本。不要绕过产品限制，直接套用自建的 pg_upgrade 文件操作。

五、自建和托管混用，时间怎么排？

可以把计划按条件分成几步，而不是先定一个死日期。社区正式版可用后，先在自建测试环境验证应用；目标云产品正式支持后，再验证云上权限、扩展和高可用；两边都通过，才定切换窗口。

如果程序同时连接自建和托管库，新 SQL 应以实际最低支持版本为准。需要只在 19 才有的功能时，要明确把旧版本连接排除，不能让同一段代码随机打到不支持它的实例。

迁移还要选对复制方法，跨主版本不能直接当成同版本物理备库处理。采用逻辑复制时，范围之外的对象和最后切换步骤仍需单独安排。

六、如果只是想尝鲜，怎样安排更合适？

尝鲜时先用短期测试库验证明确的一项需求，不必一开始搬完整生产系统。留意预览保留期限、费用和导出方式，样本不要包含生产敏感内容。

服务商正式开放、项目依赖可用、完整演练可接受，三个条件齐全再定生产时间。等待时先做好应用测试与迁移准备，比猜开放日期更有价值。