云 PostgreSQL 服务版图
用官方能力边界理解主流托管与开发者平台
托管社区 PostgreSQL
| 服务 | 已核实的能力 | 选型时重点验证 |
|---|---|---|
| Amazon RDS for PostgreSQL | 自动备份/PITR、Multi-AZ、只读副本、VPC 与 TLS | 无主机访问；参数、系统能力和扩展来自平台允许清单 |
| Cloud SQL for PostgreSQL | 托管备份、HA/故障转移、加密、私网/公网、只读副本和维护编排 | 维护或部分配置可能重启；核对区域、扩展、连接与 AI 功能可用性 |
| Azure Database for PostgreSQL Flexible Server | 同区/跨可用区 HA、PITR、TLS、私网、托管维护、可启用内置 PgBouncer | 自动备份保留默认 7 天、最长 35 天；内置 PgBouncer 使用 6432 端口，核对池化模式 |
| 阿里云 RDS PostgreSQL | 基础版、高可用版与集群版；自动/手工备份、只读实例和数据库代理 | 高可用版备节点不可直接访问；同步模式、代理路由和备份类型随架构变化 |
| TencentDB for PostgreSQL | 托管安装、存储、HA、备份、大/小版本升级与只读实例组 | 官方说明单个只读实例不具备 HA/SLA；生产读组应核对节点数、路由和一致性 |
云厂商通常不会在社区发布当天立即提供相同内核或扩展版本。把“支持 PostgreSQL 17/18”拆成三个问题：能否新建、能否从旧版本升级、目标扩展是否支持该版本。
兼容增强型引擎
| 服务 | 架构特点 | 需要接受的差异 |
|---|---|---|
| Aurora PostgreSQL-Compatible | 定制 PostgreSQL 兼容引擎和分布式存储，以集群而非单实例为主要管理单位 | Aurora 自有版本节奏；扩展来自支持清单，不会随社区扩展自动升级 |
| AlloyDB for PostgreSQL | 计算/存储解耦、跨区 HA，可选列式引擎，并提供向量和模型集成 | 不是社区二进制等价物；验证扩展、参数、迁移工具、分析路径和区域能力 |
“PostgreSQL-compatible”适合描述迁移起点，不应作为测试结论。至少跑 schema 迁移、关键查询、事务并发、驱动、扩展和故障恢复测试。
开发者平台
| 服务 | 强项 | 容易忽略的生产问题 |
|---|---|---|
| Neon | 计算/存储分离、自动伸缩、scale-to-zero、数据库分支和池化连接 | 冷启动、计算规格变化、分支数据治理，以及 pooled/direct 连接的用途差异 |
| Supabase | 每项目完整 PostgreSQL，并集成 Auth、Storage、Realtime、API 和 Supavisor | 浏览器直连数据 API 前必须正确设计 RLS；核对备份/PITR 套餐、连接预算与平台组件耦合 |
需要零成本开发环境时，查看按 2026-08-02 核对的 免费 PostgreSQL 云数据库选型。Supabase、Neon、Nhost 与 Prisma Postgres 的平台结构不同，不能只按免费 storage 数字排序。
备份存在，不代表可以恢复
必须验证恢复粒度、保留期、跨区域副本、密钥依赖、导出能力和实测恢复时间。Azure 等平台的托管物理备份不能直接导出到平台外；退出路径通常要另做 pg_dump、逻辑复制或迁移服务。
面向 AI 工作负载
选择云 PG 承载 RAG 或 Agent 元数据时，优先核对：
pgvector的版本、HNSW/IVFFlat 支持和升级节奏；- 最大连接数与池化方式，尤其是短生命周期函数/Agent；
- 向量索引构建的内存、临时存储、WAL 和副本延迟；
- tenant/ACL 过滤后的真实召回率，而非无过滤基准；
- embedding 模型、向量数据和数据库是否满足同一驻留边界；
- 是否能导出原文、metadata 与 embedding，避免数据管道锁定。
云厂商集成的模型端点、自动 embedding 或 AI 助手能减少胶水代码，但也增加权限、区域、模型生命周期和成本维度；它们不能替代数据库侧的 RLS、最小角色和检索评测。
如果候选只支持 PostgreSQL protocol 或复用了 query layer，继续检查 PostgreSQL 血缘与兼容数据库。
Last updated on