35 选择一个你能离开的服务商

截至 2026 年 10 月，AWS 给出的数据如下：

• gp3 包含 3,000 IOPS 的基线（托管一章展示了触及该上限时的表现），最高可预置 80,000 IOPS 和 2,000 MiB/s，没有突发能力（AWS）。持久性标为“99.8% - 99.9%”（AWS）。
• io2 Block Express“设计目标是在 16KiB I/O 操作下提供低于 500 微秒的平均延迟”，在 Nitro 实例上可达 256,000 IOPS，标称持久性为“99.999%”，按预置 IOPS 收费。
• r8g.xlarge 的基线为 6,000 IOPS 和 156.25 MB/s，最高为 40,000 IOPS 和 1,250 MB/s；该档位的实例“每 24 小时至少能以最高性能持续运行 30 分钟，此后恢复到基线性能”（AWS）。
• i8g.xlarge 在 4 KiB、满队列深度下，标称随机读 IOPS 为 150,000，写 IOPS 为 82,500（AWS）。AWS 提醒：“不要依靠实例存储卷保存有价值的长期数据”（AWS）。

Google 的 Local SSD“物理连接到服务器”，但“只能提供临时存储”（Google）。AWS 也会把本地 NVMe 用于更有限的用途：RDS Optimized Reads 将临时表放在本地存储上，使“查询性能最高提升 50%”，而数据仍留在 EBS 上（AWS）。

根据其方法说明文章：

• **被测系统：**PlanetScale 的 M-320，一个 i8g 节点（4 vCPU、32 GB RAM、937 GB 本地 NVMe），以一个主库和两个副本的形式分布在三个可用区；只有主库承载测试。
• **其他系统：**vCPU 和内存与之相当或更多的单实例，例如使用 db.r8g.xlarge 的 Aurora 和 8 个计算单元的 Neon，它们都“使用网络附加存储”。
• **工作负载：**Percona 的类 TPCC sysbench 脚本，规模设为“产生约 500 GB 的 Postgres 数据库”，分别以 32 和 64 个连接运行 5 分钟；在“约 300 GB”的数据集上运行 sysbench 只读测试；以及反复执行 SELECT 1 测量往返延迟。除连接数限制和超时外，设置“保持各平台的默认值”；成本对比则用它自己的三节点价格，与各对手加上副本后的价格比较。

PlanetScale 公布的主要类 TPCC 结果：自身约 18,000 QPS，Aurora 约 12,000（Aurora 页面），Neon 约 12,500（Neon 页面），AlloyDB、Crunchy Data、Supabase、TigerData 和 Heroku 则更低。只读测试中，PlanetScale 和 Aurora 都“约为 35,000 QPS”，PlanetScale 的 p99 更稳定。它的架构页面表示，变更会“由至少一个副本确认”。

• Xata（2025 年 7 月 16 日）在自己的 NVMe-over-Fabrics 网络存储上运行了这项测试，为本次测试调优 Postgres 后，8 vCPU、64 个连接下报告约 25,000 QPS，4 vCPU 下约 20,000。它称自己的图表“不是同等条件下的比较”，并批评了测试方法：运行前没有执行检查点或清理，默认配置未经调优，工作负载“写入非常密集”。PlanetScale 回应称 Xata 针对该工作负载做了调优，并拒绝提供访问权限让 PlanetScale 复现。
• Neon（2025 年 7 月 11 日）使用 NVMe 上 500 GB 的本地缓存重新测试，报告 17,030 QPS，而默认设置下为 12,512；若将缓存设为与工作集相当的 180 GB，峰值 QPS 低约 10%。它的反驳是：固定大小的本地磁盘会迫使你购买更高一档的实例。

截至 2026 年 10 月：

**Amazon RDS for PostgreSQL。**使用 EBS 的虚拟机，容量最高 64 TiB（AWS）。标准支持涵盖 14 到 18，当前版本为 18.6；19 仅出现在预览环境中，而且“不能将预览版本用于生产”（发布日历、预览）；目标是在社区新大版本的第一个小版本发布后 30 天内提供该大版本。支持的扩展很多（AWS）；可以选择“不承担读流量”的 Multi-AZ 备库，或具有两个可读半同步备库的集群（AWS）；最多 15 个只读副本。没有超级用户时，通过 pg_dumpall --globals-only --no-role-passwords 导出角色，再手动重置密码。旧大版本转入付费 Extended Support，按 vCPU 小时收费，最长三年，备库也收费（AWS）。按实例小时、存储、额外 IOPS 和备份存储计价（AWS）。

**Amazon Aurora PostgreSQL。**一个跨三个可用区的共享卷，“可增长至 256 TiB”，最多承载 15 个副本（AWS）。2026 年 6 月 11 日开始提供 PostgreSQL 18；大版本的目标是在社区第一个小版本发布后的八个月内提供（AWS）。Global Database 可扩展到“最多 10 个只读的辅助 AWS 地域”，延迟“通常不到一秒”（AWS）。Aurora serverless 可“从 0 ACU 扩展至 256 ACU”，每个 ACU 约 2 GiB；13.15、14.12、15.7、16.3 及更高版本支持自动暂停（AWS、自动暂停）。Limitless Database 自 2024 年 10 月正式可用，提供分片（托管分片 Postgres）。迁出只能走逻辑方式，由 Aurora 充当发布者（AWS）。I/O-Optimized 不再按 I/O 请求计费，“每 30 天”可以切换一次（AWS；何时划算）。

**Aurora DSQL 是另一种数据库。**自 2025 年 5 月正式可用，基于 PostgreSQL 16，但隔离级别“固定为 PostgreSQL 的可重复读”，发生冲突会报错而不是等待，也没有临时表、触发器和 PL/pgSQL（AWS）。和那些分布式 SQL 数据库一样，采用它需要做一次迁移。

Google Cloud SQL。“每个 Cloud SQL 实例由一台虚拟机提供支持”，使用网络磁盘（Google）；提供 9.6 到 18，默认为 18.6（Google）。从 16 起默认使用 Enterprise Plus，它增加了本地 SSD 缓存、读取池、“停机不到一秒”的维护、“最长 35 天”的 PITR 日志（Enterprise 为 7 天）和 99.99% 的 SLA（Google）。高可用模式会同步写入两个可用区的磁盘（Google）。延长支持自 2025 年 5 月 1 日起收费（Google）。按 vCPU 和内存计费，高可用价格翻倍（价格）。

AlloyDB。“跨多个可用区的存算分离架构”（Google），附有分析用的列式引擎（Google）。18 于 2026 年 3 月 18 日正式可用；大版本在社区正式发布后“五个月内”提供（Google）。连续备份保留 1 到 35 天，“RPO 为零”（Google）；不收 I/O 费用（价格）。AlloyDB Omni 在你自己的数据中心、任意公有云或笔记本上运行同一套引擎，按 vCPU 授权（Google）。迁出要通过 pglogical 或 pg_dump 等逻辑方式（扩展、导出）。

Azure flexible server。“数据库引擎运行在 Linux 虚拟机内的容器中”，数据有“三份本地冗余的同步副本”（Microsoft）。存储最高 64 TiB（Microsoft）；当前版本为 18.6（Microsoft）。提供“零数据丢失”的可用区冗余高可用、五个只读副本（Microsoft），以及“开源 Citus 扩展的托管服务”弹性集群（Microsoft）。在 18 上，“不能将服务器配置为使用新的异步 I/O io_method = io_uring”。Microsoft 表示，11 到 13 的延长支持自“2026 年 9 月 1 日”开始计费，且无法退出（Microsoft）。按 vCore 加存储计费（Microsoft）。Azure HorizonDB“目前处于预览阶段”，它才是存算分离的服务：“数据页不会从计算副本写入存储层”（Microsoft）。

截至 2026 年 10 月：

**Crunchy Bridge 和 Snowflake Postgres。**Snowflake 于 2025 年 6 月 2 日宣布计划收购 Crunchy Data；其后续博客表示“2025 年 6 月，Snowflake 收购了 Crunchy Data”（新闻稿、博客）。Crunchy Bridge 在 AWS、Google Cloud 和 Azure 上运行虚拟机，提供 15 到 18（2026 年 5 月起新集群不再提供 15），并给予“你的 Postgres 超级用户账户”（版本、用户）；每 60 秒归档一次 WAL，保留 10 天；高可用“使集群价格翻倍”（HA、套餐）。Snowflake Postgres 于 2026 年 2 月 24 日正式可用，运行 16 到 18，提供 10 天 PITR，但其管理员“不是完整的 Postgres 超级用户”（Snowflake、角色）。

**Aiven。**运行在各大云上的虚拟机，提供 13 到 18，上游结束支持时相应版本也退役（Aiven）；Business 有一个备库，Premium 有两个（Aiven）。“除少数例外，无法安装仅超级用户可用或不受信任的扩展”；按套餐保留 2 到 30 天的备份（Aiven）；有免费档（Aiven）。

**EDB Postgres AI Cloud Service。**EDB“将不再向新客户提供 Hosted Cloud Service 选项”；继续提供在客户自己的云账户中管理集群的服务（EDB）。Advanced Server 现名为“Enterprise Postgres (Oracle Compatible)”（EDB），每 vCPU 小时的价格是社区 PostgreSQL 的三倍（EDB）；它的 Oracle 功能无法迁移到社区 Postgres。

**Fly.io Managed Postgres。**每个套餐都包括“一个主库和副本、PgBouncer 和备份”，提供 16 和 17，容量最高 1 TB（Fly.io）；Fly.io 将“安全补丁和版本升级”列为“开发中”。旧的非托管 Fly Postgres“已不再维护”（Fly.io）。

**PlanetScale Postgres。**2025 年 9 月 22 日正式可用：一个主库和两个副本跨可用区部署，可使用本地 NVMe（“Metal”）或网络存储，提供 17 和 18（正式发布、版本），通过逻辑复制提供 CDC（PlanetScale）。Metal“存储容量由实例大小固定”；备份默认“保留 2 天”（PlanetScale）；Neki 分片“目前处于 Platform Preview”（PlanetScale）；按集群大小定价（PlanetScale）。

Tiger Cloud。“Timescale 现已更名为 Tiger Data”（2025 年 6 月 17 日，Tiger Data）：在 16 到 18 上运行 TimescaleDB（Tiger Data），面向超出建模一章中 BRIN 和分区能力范围的事件数据。“Tiger Cloud 不提供超级用户访问”（Tiger Data）；PITR 为 3 或 14 天；按计算小时加存储收费（Tiger Data）。

**DigitalOcean。**提供 14 到 18（DigitalOcean），PITR 可回到“过去七天内”（DigitalOcean），没有超级用户。对新账户自 2026 年 10 月 15 日起，对全部账户自 11 月 30 日起，新建的 Standard Edition 集群“不能使用超过 4 GiB 内存的套餐，也不能添加备库或只读节点”；高可用移到更贵的 Advanced Edition。

**Render。**提供 13 到 18（Render）；高可用由异步备库在 30 秒后接管（Render），这可能丢失最后几笔提交；PITR 为 3 或 7 天（Render）；免费数据库“创建 30 天后到期”（Render）。

**Heroku Postgres。**Advanced 档采用“计算与存储解耦”架构，容量最高 100 TB，目前处于“有限正式可用”阶段（Heroku、Advanced）；默认版本为 18（Heroku）。所有者“比超级用户低一级”（Heroku）；故障切换可能丢失“少量但有明确上限的最近已提交数据”（Heroku）。2026 年 2 月 6 日，Heroku 表示正在“转向以维护为主的工程模式……而不是引入新功能”（Heroku）。

截至 2026 年 10 月：

**Neon。**计算与存储由“一条预写式日志（WAL）记录流”连接，现在以 Lakebase Postgres 为品牌（Neon）；Databricks 于 2025 年 5 月 14 日宣布计划收购 Neon，而 Neon“已是 Databricks 平台的一部分”（Databricks）。提供 14 到 18（Neon）。空闲 5 分钟后缩容至零，“几百毫秒内”唤醒（Neon）；可“从当前或过去的状态”创建分支（Neon）；恢复窗口按套餐最长为 30 天。大版本升级意味着新建项目；保持连接的逻辑复制订阅者会使计算实例保持唤醒，非活动的复制槽约 40 小时后会被删除（Neon）。按计算单元小时计费，有免费套餐（Neon）。

**Supabase。**每个项目一个 Postgres 实例，配上一套平台服务：Auth、通过 PostgREST 提供的 REST API、Realtime、Storage 和 Edge Functions（Supabase），运行 PostgreSQL 15 或 17（Supabase）。基于行级安全构建，有文档说明如何通过逻辑复制向外传输数据（Supabase）。分支“默认不含数据”（Supabase）；PITR 是附加服务，至少需要 Small 计算规格；无需清理的存储引擎 OrioleDB“处于公开测试阶段”（Supabase）。套餐加计算加用量计费（Supabase）。

Xata。“原生支持分支的 Postgres”：每个分支都是“底层逻辑卷的写时复制快照”（Xata），支持匿名化克隆；提供 14 到 18（Xata）；可运行在 Xata 的云、你的云，或自托管环境中（Xata）。只能原地进行小版本升级；Xata 的公开文档没有描述备份或 PITR。

**Nile。**面向多租户 SaaS 的 Postgres：每个存储页属于一个租户，租户可以放在共享或专用计算实例上（Nile），也就是分片一章里手动完成的事情。只提供 PostgreSQL 15，而且租户表上不支持用户定义函数、触发器和序列（Nile）。

**Railway。**不是托管服务：它的模板是“非托管服务”，备份、调优、安全和监控“由你负责”（Railway）。可选 Patroni 高可用（Railway）；备份是卷快照，并非基于 WAL 的恢复（Railway）。

还有规模更小的服务，例如按操作次数计费的 Prisma Postgres（Prisma）。

截至 2026 年 10 月：

• Patroni：“一个用于构建 PostgreSQL 高可用（HA）集群的 Python 模板”，用 etcd、Consul、ZooKeeper 或 Kubernetes 进行领导者选举；MIT，支持 PostgreSQL 9.3 到 18（GitHub）。
• **pgBackRest：**向 S3、Azure 或兼容 GCS 的存储执行全量、差异和增量备份，支持 PITR（pgbackrest.org）。维护者于 2026 年 4 月 27 日宣布“不再维护”，随后在 5 月 18 日宣布“一个赞助商联盟已联合起来，资助后续开发”（新闻）。
• WAL-G（Apache-2.0）和 Barman（GPL-3.0）（WAL-G、Barman）。
• **CloudNativePG：**一个“直接与 Kubernetes API 集成”而不使用 Patroni 的 Operator；Apache-2.0，自 2025 年 1 月起成为 CNCF Sandbox 项目，通过其 Barman Cloud 插件执行备份（GitHub、CNCF）。
• **Crunchy Postgres for Kubernetes（PGO）：**Patroni 加 pgBackRest，Apache-2.0；其默认镜像受 Crunchy Data Developer Program 条款约束，所以先读这些条款（GitHub）。
• **Zalando postgres-operator：**通过 Spilo 镜像使用 Patroni，MIT，支持 PostgreSQL 14 到 18（GitHub）。
• **StackGres：**AGPL-3.0，基于 Patroni，带有 Web 控制台和大量扩展（StackGres）。Percona Operator for PostgreSQL“基于 Crunchy Data 开发的 Postgres Operator”，Apache-2.0（GitHub）。