AWS RDS for PostgreSQL 与 Aurora

AWS 为 PostgreSQL 工作负载提供两条托管路径，但二者不是同一个产品。Amazon RDS for PostgreSQL 把社区内核作为托管实例运行；Aurora PostgreSQL-Compatible 是 AWS 自研分布式存储之上的 PostgreSQL 兼容引擎，以集群而非单实例为管理单位。驱动和大多数 SQL 在两边都能工作，但参数、扩展、故障转移和计费行为并不一致。跨厂商视角见云服务版图。

什么时候选哪一个

以下情况默认选 RDS for PostgreSQL：

• 希望行为尽可能接近社区 PostgreSQL（在托管服务允许的范围内）；
• 单主加可选 Multi-AZ 备库和只读副本即可满足可用性目标；
• 存储远低于 64 TiB 上限，且偏好预分配、可预期的容量规划。

以下情况 Aurora PostgreSQL-Compatible 才值得它的溢价：

• 需要更快的故障转移，以及共享同一集群存储卷的最多 15 个 Aurora 副本做读扩展；
• 希望存储按 10 GiB 步长自动增长（上限 256 TiB），而不是提前预分配；
• 愿意接受拥有独立发布节奏、版本编号和扩展清单的引擎。

这不是推荐排名。两者都是无主机访问的托管服务，正确选择取决于你实测的故障转移、连接和成本需求。

RDS 与 Aurora 并排对比

需要接受的差异

• Aurora 的 max_connections 计算方式不同。 默认值为 LEAST({DBInstanceClassMemory/9531392}, 5000)——16 GiB 内存的实例约 1,800 个连接，且无论实例多大上限都是 5,000。高并发应用需要在任一服务前放置 RDS Proxy 或 PgBouncer；参见 Aurora 参数参考。
• 扩展可用性是按引擎划分的允许清单。 在 RDS 上可用的扩展（如 pg_repack）在 Aurora 上可能缺失或版本被锁定。迁移前先把 pg_extension 清单与 Aurora 支持矩阵比对，而不是迁移之后。
• Aurora 以集群为单位管理。 部分参数集群级生效，部分系统视图和等待事件与社区 PostgreSQL 不同，存储按消耗量加 I/O 请求计费而非预分配容量。
• 两个服务都不提供主机或 superuser 访问。 rds_superuser 是裁剪过的角色；任何需要 OS 访问、任意 shared_preload_libraries 或 untrusted 语言的方案在两边都行不通。

生产前验证

1. 把已安装扩展及其确切版本与目标引擎的允许清单逐一比对。
2. 做一次真实故障转移演练，计时应用的重连行为，而不只是 DNS 切换。
3. 从 max_connections 出发核算连接预算，再决定 RDS Proxy 或 PgBouncer 及其池化模式。
4. 向全新实例或集群执行一次 PITR 恢复，实测 RPO/RTO。
5. 用真实 I/O 水平建模成本——Aurora 单独计 I/O 请求费，从预分配存储的 RDS 迁来时常被这点打个措手不及。
6. 用 pg_dump 或快照导出一次，并在独立的 PostgreSQL 环境中恢复，作为退出路径验证。

连接池、备份演练和监控基线等与厂商无关的内容见生产环境技术栈。如果只需要开发或评估用数据库，免费 PostgreSQL 选型列出了零成本替代方案。