数据库用了很久，应用也一直能跑，最容易把升级排到“以后再说”。选Cloud SQL时，我会把这份以后要做的工作提前写进计划。托管让一些日常维护更方便，应用与数据库主版本是否兼容，仍需要有人认真安排。
如果你正准备搬一套旧应用，先查主版本的支持时间，再决定沿用多久。 仅比较今天的实例规格，会漏掉继续留在旧版本可能多付的费用。
还能运行，不代表一直只有原来的费用
Cloud SQL会在相应主版本进入扩展支持时自动纳入该服务，并在常规实例费用之外收费。[2] 时间要按Cloud SQL对该主版本的日历核对，不能直接把社区停止支持当天当成所有实例的计费起点。
扩展支持可以给你安排升级的时间，但它是需要预算的过渡期。拟好了升级计划，并不会让费用立刻停止；升级完成并进入常规支持版本后，才停止对应的扩展支持附加费。[2]
| 现在的项目状态 | 我会先做什么 | 预算重点 |
|---|---|---|
| 新项目还没定版本 | 核对受支持版本与应用依赖 | 避免刚部署就留下升级债务 |
| 旧库工作正常，准备继续使用 | 确认支持日历，安排验证 | 实例之外的扩展支持费用 |
| 已经准备迁移或升级 | 测兼容、恢复与切换步骤 | 过渡环境和必要副本 |
升级先从最担心坏掉的地方试
我会列出应用依赖的扩展、常用查询、导入导出过程和后台任务，优先验证最难补救的环节。测试不要只停在“能连接数据库”：能连接，但某个夜间任务出错，同样会让迁移很被动。
再准备一条可解释的退路：数据怎样保存、如何判断切换成功、失败后由谁决定下一步。这是建议你在自己的环境中验证的工作，本文没有执行升级，不能替你证明兼容性或切换时间。
看实例时，副本和高可用要放回自己的那一行
Cloud SQL有Enterprise与Enterprise Plus等方案方向，价格条件随版本、地区和资源而变化；读取副本自身也计费，HA需要使用对应配置的计量条件。[1] 不要看到主实例某一行价格，就把副本顺手当成其中附送的部分。
同样，1年或3年的承诺价格要按适用条件比较，不能当成随时可退出的按需价。[1] 如果迁移后会不会扩大、地区是否改变还没确定，我会先保留调整空间，等运行方式稳定后再讨论长期安排。
我会给旧库留一个真正能执行的日期
把支持日历、兼容性验证、数据保存和切换负责人写下来，安排一个现实的时间。要是暂时不能升级，也知道延后的预算来自哪里，而不是等账单变化后才发现一直拖着的决定。
新项目选版本时就核对支持日历；旧库准备继续用，则给兼容性验证和切换安排日期。暂时不能升级，也把扩展支持费用单列出来，拟了计划不会立即停止收费。本文没有执行升级，配置报价和副本成本仍需按自己的地区确认，能连接也不能替代业务兼容性验证。
资料核对与适用范围
本轮重读Cloud SQL PostgreSQL扩展支持政策，价格页完整读取失败，版本与副本计量方向仅核对官方检索摘要；未新增具体费率。按版本维护与升级准备作资料评估，不代表本站数据库使用、升级演练或账单体验。
地区、系统许可、账户类型、部署方式、资源保留与适用计费条件需按实际账户核对。本站未登录商家、租机、上传对象、创建数据库、恢复备份或付费调用；本文不能证明实际性能、恢复时间或最终账单。