选托管还是自托管，判断依据集中在四件事上。你要的数据库版本与扩展托管方是否支持，团队能不能承担故障时的第一响应，你对数据和网络路径的控制要求有多高，总拥有成本的临界点落在哪里。PostgreSQL 官方对每个主版本提供五年支持，托管服务把这段支持期、备份、主从切换和补丁安装打包成产品，值不值取决于你的团队有没有把这几件事做成例行工作。
官方支持期的五年是成本计算的起点
PostgreSQL 全球开发组对每个主版本提供五年支持，从首次发布算起，到期后发布最后一个次版本并终止支持。主版本大约每年一个新版，次版本至少每三个月发布一次，包含安全修复和数据损坏问题的修复。
这条时间线决定两种模式的成本结构。自托管时，主版本升级、次版本跟进、扩展兼容性验证都由你排期。托管服务通常提供升级窗口和自动的次版本更新，代价是升级时机不由你决定。
大版本升级还有一条硬约束。主版本之间数据目录不向后兼容，必须导出重建或者使用 pg_upgrade 工具。
自托管的真实工作量在哪
自托管省下订阅费，付出的是把高可用做出来的人力。官方文档列出的方案包括日志传送的备用服务器、流复制、复制槽、级联复制和同步复制，再加上持续归档。
- 先定恢复目标。允许丢多少数据、允许停多久，这两个数字定下来再选复制方式。
- 搭建物理备用节点，配置流复制和复制槽，确认复制延迟可接受。
- 把故障切换流程写成可执行步骤，包括提升备用节点、切换连接串、处理原主节点回归。
- 定期演练。没演练过的切换流程等于没有流程。
- 备份与恢复验证纳入日常。备份文件存在不等于能恢复。
这五件事任意一件没做好，自托管的隐患就超过省下的费用。团队已有成熟自动化在跑的话，边际成本会明显下降。
托管省掉了什么，又交出了什么
托管服务替你承担可用性承诺、备份与时间点恢复、硬件故障处理，以及一部分监控告警，多数产品还提供只读副本和连接池。交出去的部分同样具体。
- 版本与扩展的选择空间。托管方支持的扩展列表和权限限制，会挡住需要内核级扩展的方案。
- 网络路径与延迟。应用与数据库之间的链路要经过托管方网络，跨区域访问无法靠自建专线优化。
- 故障时的排查深度。拿不到主机层面日志和指标时，定位慢查询更难。
- 退出成本。把数据搬走需要停机窗口和足够带宽，这部分常在决策时被忽略。
按约束条件做判断
条件清楚的时候选择并不纠结。
- 团队没有专职数据库运维，业务又要求较高可用性，托管通常更划算。
- 业务依赖特定 PostgreSQL 扩展或需要调整内核参数，先确认托管方是否支持，不支持只能自建。
- 合规要求数据不出境或必须落在自有网络时，自建或私有化部署是前提。
- 负载稳定且规模不大，自建主从加备份的成本算得清楚。
- 团队已有成熟的容器编排和自动化运维能力，自托管的边际成本低。
务实的做法是混合。核心交易库放在自建或私有化环境保证控制力，分析型副本和测试环境放在托管服务上。
常见问题
托管数据库的性能会差一些吗。同规格下差别主要来自网络路径和参数预设，不在数据库本身，选型时要测应用与数据库之间的实际往返延迟。
迁移到托管危险吗。风险主要在切换窗口和数据一致性验证。先在预发环境跑一遍完整迁移，确认时间点恢复可用再动生产。