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

> 2026 年 10 月，Postgres 可以运行在哪里，为什么有些服务商的基准测试成绩更快，以及如何选择一个你能离开的服务商。

---

LLMS 索引： [llms.txt](/llms.txt)

---

<span id="basics-chapter-35"></span>

两家服务商，同样的 4 vCPU 和 32 GB RAM，同样的基准测试。一家厂商公布的结果是自己每秒处理 18,000 次查询，对手则是 12,000 次。即便照单全收，这些数字也不能说明哪家的 PostgreSQL 更好。其中一家把页面放在机器内部的硬盘上，另一家则把它们放在网络另一端的存储上，而数据集大小是内存的十五倍。

服务商之间的差异大多如此。在缓冲区缓存之上，大家运行的是同一个引擎。在它之下以及周围，各家的选择不同：页面放在哪里，谁掌握超级用户权限，哪些东西要收费，以及离开有多难。

先决定购买多少托管，再决定向谁购买；[能负担多少托管，就购买多少托管](/34-managed/#buy-as-much-management-as-you-can-afford)一节阐述了理由。之后我们的建议很简单：按你现有的工作负载选择，而且要选一个你能离开的服务。

> [!NOTE] 来源与日期
>
> 厂商资料来自各服务商截至 2026 年 10 月的文档、价格页或博客，链接随文给出；据此设计方案前，请先检查链接。排列顺序不是排名，我们的观点会明确标出。版本方面：PostgreSQL 18 是最新正式版；19 在 2026 年 9 月 24 日发布了 Beta 4，项目表示正式版“也可能在 10 月发布”（[PostgreSQL](https://www.postgresql.org/about/news/postgresql-19-beta-4-released-3386/)）。这里还没有服务商提供可用于生产的 19。

## 了解架构形态，就了解了取舍 {#know-the-shape-and-you-know-the-tradeoffs}

每个选项都属于五种架构之一，或者是它们的混合；还没读功能清单，架构形态就能告诉你大部分取舍。

| 形态 | 页面存放位置 | 长处 | 代价 | 示例 |
|---|---|---|---|---|
| 传统托管 | VM 加网络卷 | 熟悉、可迁移 | 每次未命中都要走一趟网络 | RDS、Cloud SQL、Azure |
| 本地 NVMe | 机器内的硬盘 | 超出内存后仍然快 | 持久性由副本承担 | PlanetScale Metal |
| 存算分离 | 以 WAL 为输入的存储 | 副本共享存储，自动扩容 | 专有存储 | Aurora、AlloyDB |
| 无服务器 | 存算分离，可缩容至零 | 空闲成本低，支持分支 | 冷启动，繁忙时账单高 | Neon |
| 平台套装 | 上述任一种 | 认证、API、存储 | 应用的更多部分依赖同一家厂商 | Supabase |

<span id="tbl-35-1"></span>

**Table 35-1.** 了解架构形态，就了解了取舍


大多数专业服务商也采用传统托管架构。

在虚拟机或 Kubernetes 上自行管理是第六个选项，可以采用前三种形态中的任一种。

## 存储决定基准测试结果 {#storage-decides-the-benchmark}

一家服务商在相同 vCPU 和内存下公布了另一家两倍的吞吐量时，先看磁盘。一旦[工作集（working set）](/43-glossary/#working-set)无法全部放入内存，页面的位置就决定了速度。

[延迟一章](/03-latency/#memory-is-cheap-everything-else-is-expensive)列出了这个阶梯：内存是纳秒级，本地 NVMe 是几十微秒，网络存储则是几百微秒或更长。这个阶梯只在缓存未命中时才有意义（[shared_buffers 是页的数组](/05-buffers/#shared_buffers-is-an-array-of-pages)）。如果热点页面都能放进内存，这三种存储设计表现就差不多。

### 网络块存储：每次未命中都要一次往返 {#network-block-storage-every-miss-is-a-round-trip}

RDS、Cloud SQL、Azure 和大多数专业服务商把数据目录放在网络卷上，因此一次未命中内存的读取，就会变成发往数据中心其他位置的存储服务器的请求。卷有 [IOPS](/43-glossary/#iops) 上限，而前面的实例往往有一个更低的上限：EC2 `r8g.xlarge`（4 vCPU、32 GiB）的突发额度耗尽后，只能持续提供 6,000 IOPS，不管你买的是什么卷（[两个上限，你会撞上其中较低的那个](/34-managed/#two-ceilings-and-you-hit-the-lower-one)）。

即便如此，它仍然有理由成为默认选择。卷的寿命不依赖实例，主机坏了只需重新挂载，无需重建。快照便宜，存储和计算可以独立扩缩容，甚至单个实例也能承受磁盘故障，因为底层存储会进行复制（但并非永远可靠：AWS 给 gp3 标出的年持久性是 99.8% 到 99.9%）。

### 本地 NVMe：快，但会随主机一起消失 {#local-nvme-fast-and-gone-with-the-host}

实例存储就是同一台机器里的硬盘。AWS 给 `i8g.xlarge` 标出的性能是：同样的 4 vCPU、32 GiB，单块 937 GB 硬盘提供 150,000 随机读 IOPS，是网络路径 6,000 IOPS 的二十五倍。

代价是持久性。AWS 表示：“实例停止、休眠或终止后，数据不会保留。”因此，本地 NVMe 上的数据库要通过[复制](/38-replication/#basics-chapter-38)获得持久性，这会带来一些后果。一次提交必须到达另一个可用区的副本才算安全，这[需要一次往返](/38-replication/#synchronous-commit-costs-a-round-trip)。丢失的节点要靠复制整个数据库来重建，TB 级数据需要数小时。而磁盘大小也与实例大小绑定：硬盘装不下了，就得迁移到更大的节点。

<span id="the-volume-and-instance-numbers-as-aws-and-google-publish-them" class="pgbasics-deep-dive-anchor" data-td-print-local></span><span id="basics-35-the-volume-and-instance-numbers-as-aws-and-google-publish-them" class="pgbasics-deep-dive-anchor"></span>

> [!DETAILS]- 深入阅读：AWS 和 Google 公布的卷与实例数据
>
> 截至 2026 年 10 月，AWS 给出的数据如下：
>
> - **gp3** 包含 3,000 IOPS 的基线（[托管一章](/34-managed/#the-volume-is-your-bottleneck-now)展示了触及该上限时的表现），最高可预置 80,000 IOPS 和 2,000 MiB/s，没有突发能力（[AWS](https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html)）。持久性标为“99.8% - 99.9%”（[AWS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html)）。
> - **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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html)）。
> - **`i8g.xlarge`** 在 4 KiB、满队列深度下，标称随机读 IOPS 为 150,000，写 IOPS 为 82,500（[AWS](https://docs.aws.amazon.com/ec2/latest/instancetypes/so.html)）。AWS 提醒：“不要依靠实例存储卷保存有价值的长期数据”（[AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-store-lifetime.html)）。
>
> Google 的 Local SSD“物理连接到服务器”，但“只能提供临时存储”（[Google](https://docs.cloud.google.com/compute/docs/disks/local-ssd)）。AWS 也会把本地 NVMe 用于更有限的用途：RDS Optimized Reads 将临时表放在本地存储上，使“查询性能最高提升 50%”，而数据仍留在 EBS 上（[AWS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PostgreSQL.optimizedreads.html)）。

### 日志结构存储：发送 WAL，而非页面 {#log-structured-storage-ship-wal-not-pages}

Aurora、AlloyDB、Neon 和 Azure 的 HorizonDB（预览版）把 WAL 发送给据此构建页面的存储服务，因此写入要等待网络上达到法定人数的节点确认；读取未命中则要从网络获取数据，本地缓存能缓解这一开销。这会怎样影响调优，参见[分离式存储改变了部分规则](/34-managed/#disaggregated-storage-changes-some-rules)。选型时的差异在账单上：Aurora Standard 按每百万次 I/O 请求收费，AlloyDB 不收 I/O 费用，Neon 的本地缓存则可以溢出到 NVMe。

### 最知名的基准测试用十五倍于内存的数据测试存储 {#the-best-known-benchmark-tested-storage-at-fifteen-times-ram}

最知名的对比来自 PlanetScale，随其 Postgres 产品于 2025 年 7 月 1 日发布，截至 2026 年 10 月仍在它的[基准测试页面](https://planetscale.com/benchmarks)上。在 32 GB 的机器上，用大约 500 GB 的数据库进行类 TPCC 测试，它报告自己在本地 NVMe 上约为 18,000 QPS，而 Aurora 约为 12,000。所有这些都是厂商公布的结果；我们没有复现过。

架构解释了这种表现。数据集是内存的十五倍，大部分读取无法命中内存：NVMe 上是一次本地读取，其他架构则要在 IOPS 限制之下走一次网络往返。PlanetScale 反过来在每次提交时承担网络开销，等待另一个可用区的副本，却省下了每次读取未命中的网络开销。竞争对手的回应也印证了这个物理事实：把热点页面放到本地闪存或内存中，网络的影响就会减小。

<span id="the-planetscale-benchmark-its-method-and-the-replies" class="pgbasics-deep-dive-anchor" data-td-print-local></span><span id="basics-35-the-planetscale-benchmark-its-method-and-the-replies" class="pgbasics-deep-dive-anchor"></span>

> [!DETAILS]- 深入阅读：PlanetScale 的基准测试、方法和各方回应
>
> 根据其[方法说明文章](https://planetscale.com/blog/benchmarking-postgres)：
>
> - **被测系统：**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 页面](https://planetscale.com/benchmarks/aurora)），Neon 约 12,500（[Neon 页面](https://planetscale.com/benchmarks/neon-lakebase)），AlloyDB、Crunchy Data、Supabase、TigerData 和 Heroku 则更低。只读测试中，PlanetScale 和 Aurora 都“约为 35,000 QPS”，PlanetScale 的 p99 更稳定。它的[架构页面](https://planetscale.com/docs/postgres/postgres-architecture)表示，变更会“由至少一个副本确认”。
>
> - **Xata**（[2025 年 7 月 16 日](https://xata.io/blog/reaction-to-the-planetscale-postgresql-benchmarks)）在自己的 NVMe-over-Fabrics 网络存储上运行了这项测试，为本次测试调优 Postgres 后，8 vCPU、64 个连接下报告约 25,000 QPS，4 vCPU 下约 20,000。它称自己的图表“不是同等条件下的比较”，并批评了测试方法：运行前没有执行检查点或清理，默认配置未经调优，工作负载“写入非常密集”。PlanetScale [回应](https://planetscale.com/benchmarks/xata)称 Xata 针对该工作负载做了调优，并拒绝提供访问权限让 PlanetScale 复现。
> - **Neon**（[2025 年 7 月 11 日](https://neon.com/blog/separation-of-storage-and-compute-perf)）使用 NVMe 上 500 GB 的本地缓存重新测试，报告 17,030 QPS，而默认设置下为 12,512；若将缓存设为与工作集相当的 180 GB，峰值 QPS 低约 10%。它的反驳是：固定大小的本地磁盘会迫使你购买更高一档的实例。

### 读基准测试数字前，先问是谁跑的 {#ask-who-ran-a-benchmark-before-you-read-its-numbers}

这些问题适用于所有厂商的基准测试，包括那些让你喜欢的服务显得很好的测试：

- **谁跑的？**厂商会调优自己的产品，却测试对手的默认配置；每个数字旁都该写上“厂商公布”。
- **什么工作负载？**Percona 的 README 表示其脚本“不是 TPCC 工作负载的实现”，并要求厂商在对比中说明这一点（[Percona](https://github.com/Percona-Lab/sysbench-tpcc)）。
- **数据集与内存的比例？**十五倍于内存的数据集测试的是存储。生产环境通常会按工作集能装进内存的原则配置。
- **持久性和调优相同吗？**同步副本、基于法定人数的存储确认和单个卷提供的承诺不同，[服务商的默认设置也有很大差异](/34-managed/#the-defaults-are-not-the-books-defaults)。
- **是否统一比较口径，能否复现？**每次查询的价格取决于档位、地域和副本数；公开脚本能让结论可验证。

用一天时间，在两个候选服务上运行你的模式和十条最重的查询，能获得比所有公开图表更多的信息（[如何进行测试](/29-benchmarking/#basics-chapter-29)）。

### 迁移之前，先证明问题出在磁盘 {#prove-the-disk-is-the-problem-before-you-move}

基准测试能告诉你有更快的磁盘，只有自己的数据才能告诉你是否需要。对比工作集和内存（[根据工作集配置内存](/03-latency/#size-ram-to-the-working-set)）。[采样等待事件](/31-observability/#sample-waits-to-see-where-the-time-goes)：会话主要处于 `IO` / `DataFileRead` 等待，意味着读取已经离开了内存。在 `pg_stat_statements` 中按 `shared_blks_read` 排序（[四种排名](/31-observability/#rank-the-same-view-four-ways-total-time-first)）；通常是一条查询读取了大部分页面。还要寻找上限的迹象：IOPS 持平，延迟却不断上升（[如何判断](/34-managed/#throttled-io-shows-as-flat-iops-and-rising-latency)）。

然后依次尝试便宜的修复：减少读页、增加内存、预置 IOPS、更大的实例（[先用数据证明，该换更大的机器了](/37-scale/#earn-the-bigger-box)）。做完这些，存储读取仍占主导时，再换架构。

## 超大规模云厂商胜在覆盖面，代价是复杂度 {#hyperscalers-win-on-breadth-and-cost-you-complexity}

每家大云厂商都销售传统托管服务和存算分离服务。它们胜在覆盖面：地域、合规计划，以及通往你在同一云上运行的其他一切服务的私有网络。代价是复杂度：账单上项目众多，大版本落后时还要支付延长支持费用。

<span id="rds-aurora-cloud-sql-alloydb-and-azure-entry-by-entry" class="pgbasics-deep-dive-anchor" data-td-print-local></span><span id="basics-35-rds-aurora-cloud-sql-alloydb-and-azure-entry-by-entry" class="pgbasics-deep-dive-anchor"></span>

> [!DETAILS]- 深入阅读：逐一查看 RDS、Aurora、Cloud SQL、AlloyDB 和 Azure
>
> 截至 2026 年 10 月：
>
> **Amazon RDS for PostgreSQL。**使用 EBS 的虚拟机，容量最高 64 TiB（[AWS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)）。标准支持涵盖 14 到 18，当前版本为 18.6；19 仅出现在预览环境中，而且“不能将预览版本用于生产”（[发布日历](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-release-calendar.html)、[预览](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/working-with-the-database-preview-environment.html)）；目标是在社区新大版本的第一个小版本发布后 30 天内提供该大版本。支持的扩展很多（[AWS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html)）；可以选择“不承担读流量”的 Multi-AZ 备库，或具有两个可读半同步备库的集群（[AWS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html)）；最多 15 个只读副本。没有超级用户时，通过 `pg_dumpall --globals-only --no-role-passwords` 导出角色，再手动重置密码。旧大版本转入付费 Extended Support，按 vCPU 小时收费，最长三年，备库也收费（[AWS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/extended-support.html)）。按实例小时、存储、额外 IOPS 和备份存储计价（[AWS](https://aws.amazon.com/rds/postgresql/pricing/)）。
>
> **Amazon Aurora PostgreSQL。**一个跨三个可用区的共享卷，“可增长至 256 TiB”，最多承载 15 个副本（[AWS](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.html)）。2026 年 6 月 11 日开始提供 PostgreSQL 18；大版本的目标是在社区第一个小版本发布后的八个月内提供（[AWS](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/aurorapostgresql-release-calendar.html)）。Global Database 可扩展到“最多 10 个只读的辅助 AWS 地域”，延迟“通常不到一秒”（[AWS](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)）。Aurora serverless 可“从 0 ACU 扩展至 256 ACU”，每个 ACU 约 2 GiB；13.15、14.12、15.7、16.3 及更高版本支持自动暂停（[AWS](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.how-it-works.html)、[自动暂停](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-auto-pause.html)）。Limitless Database 自 2024 年 10 月正式可用，提供分片（[托管分片 Postgres](/40-sharding/#managed-sharding-costs-you-features-and-an-easy-exit)）。迁出只能走逻辑方式，由 Aurora 充当发布者（[AWS](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Replication.Logical.html)）。I/O-Optimized 不再按 I/O 请求计费，“每 30 天”可以切换一次（[AWS](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.StorageReliability.html)；[何时划算](/34-managed/#disaggregated-storage-changes-some-rules)）。
>
> **Aurora DSQL 是另一种数据库。**自 2025 年 5 月正式可用，基于 PostgreSQL 16，但隔离级别“固定为 PostgreSQL 的可重复读”，发生冲突会报错而不是等待，也没有临时表、触发器和 PL/pgSQL（[AWS](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-migration-guide.html)）。和那些[分布式 SQL 数据库](/40-sharding/#distributed-sql-speaks-postgres-but-isnt-postgres)一样，采用它需要做一次迁移。
>
> **Google Cloud SQL。**“每个 Cloud SQL 实例由一台虚拟机提供支持”，使用网络磁盘（[Google](https://docs.cloud.google.com/sql/docs/postgres/introduction)）；提供 9.6 到 18，默认为 18.6（[Google](https://docs.cloud.google.com/sql/docs/postgres/db-versions)）。从 16 起默认使用 Enterprise Plus，它增加了本地 SSD 缓存、读取池、“停机不到一秒”的维护、“最长 35 天”的 PITR 日志（Enterprise 为 7 天）和 99.99% 的 SLA（[Google](https://docs.cloud.google.com/sql/docs/postgres/editions-intro)）。高可用模式会同步写入两个可用区的磁盘（[Google](https://docs.cloud.google.com/sql/docs/postgres/high-availability)）。延长支持自 2025 年 5 月 1 日起收费（[Google](https://docs.cloud.google.com/sql/docs/postgres/extended-support)）。按 vCPU 和内存计费，高可用价格翻倍（[价格](https://cloud.google.com/sql/pricing)）。
>
> **AlloyDB。**“跨多个可用区的存算分离架构”（[Google](https://docs.cloud.google.com/alloydb/docs/overview)），附有分析用的列式引擎（[Google](https://docs.cloud.google.com/alloydb/docs/columnar-engine/about)）。18 于 2026 年 3 月 18 日正式可用；大版本在社区正式发布后“五个月内”提供（[Google](https://docs.cloud.google.com/alloydb/docs/db-version-policies)）。连续备份保留 1 到 35 天，“RPO 为零”（[Google](https://docs.cloud.google.com/alloydb/docs/backup/overview)）；不收 I/O 费用（[价格](https://cloud.google.com/alloydb/pricing)）。AlloyDB Omni 在你自己的数据中心、任意公有云或笔记本上运行同一套引擎，按 vCPU 授权（[Google](https://docs.cloud.google.com/alloydb/omni/docs/overview)）。迁出要通过 pglogical 或 `pg_dump` 等逻辑方式（[扩展](https://docs.cloud.google.com/alloydb/docs/reference/extensions)、[导出](https://docs.cloud.google.com/alloydb/docs/export-dmp-file)）。
>
> **Azure flexible server。**“数据库引擎运行在 Linux 虚拟机内的容器中”，数据有“三份本地冗余的同步副本”（[Microsoft](https://learn.microsoft.com/en-us/azure/postgresql/overview)）。存储最高 64 TiB（[Microsoft](https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-compute)）；当前版本为 18.6（[Microsoft](https://learn.microsoft.com/en-us/azure/postgresql/configure-maintain/concepts-supported-versions)）。提供“零数据丢失”的可用区冗余高可用、五个只读副本（[Microsoft](https://learn.microsoft.com/en-us/azure/postgresql/read-replica/concepts-read-replicas)），以及“开源 Citus 扩展的托管服务”弹性集群（[Microsoft](https://learn.microsoft.com/en-us/azure/postgresql/elastic-clusters/concepts-elastic-clusters)）。在 18 上，“不能将服务器配置为使用新的异步 I/O io_method = io_uring”。Microsoft 表示，11 到 13 的延长支持自“2026 年 9 月 1 日”开始计费，且无法退出（[Microsoft](https://learn.microsoft.com/en-us/azure/postgresql/configure-maintain/extended-support)）。按 vCore 加存储计费（[Microsoft](https://azure.microsoft.com/en-us/pricing/details/postgresql/flexible-server/)）。**Azure HorizonDB**“目前处于预览阶段”，它才是存算分离的服务：“数据页不会从计算副本写入存储层”（[Microsoft](https://learn.microsoft.com/en-us/azure/horizondb/overview)）。

## 专业服务商提供更贴近需求的支持，但地域更少 {#specialists-buy-you-closer-support-and-fewer-regions}

这些公司主要销售 Postgres，其他业务不多。我们的看法是：这种专注带来了 Postgres 专属功能和更贴近需求的支持，代价是可选地域较少，以及服务背后的公司规模较小。

仔细阅读高可用和备份条款；这里的差异远大于超大规模云厂商之间的差异：[PITR](/43-glossary/#pitr) 从 2 天到 30 天不等，备库也从热备到可能丢失最近提交的异步备库不等。在明确说明权限的服务商中，只有 Crunchy Bridge 提供超级用户。

<span id="ten-specialist-services-entry-by-entry" class="pgbasics-deep-dive-anchor" data-td-print-local></span><span id="basics-35-ten-specialist-services-entry-by-entry" class="pgbasics-deep-dive-anchor"></span>

> [!DETAILS]- 深入阅读：逐一查看十种专业服务
>
> 截至 2026 年 10 月：
>
> **Crunchy Bridge 和 Snowflake Postgres。**Snowflake 于 2025 年 6 月 2 日宣布计划收购 Crunchy Data；其后续博客表示“2025 年 6 月，Snowflake 收购了 Crunchy Data”（[新闻稿](https://www.snowflake.com/en/news/press-releases/snowflake-acquires-crunchy-data-to-bring-enterprise-ready-postgres-offering-to-the-ai-data-cloud/)、[博客](https://www.snowflake.com/en/blog/engineering/meet-the-team-behind-snowflake-postgres/)）。**Crunchy Bridge** 在 AWS、Google Cloud 和 Azure 上运行虚拟机，提供 15 到 18（2026 年 5 月起新集群不再提供 15），并给予“你的 Postgres 超级用户账户”（[版本](https://docs.crunchybridge.com/concepts/postgres-versions)、[用户](https://docs.crunchybridge.com/concepts/users)）；每 60 秒归档一次 WAL，保留 10 天；高可用“使集群价格翻倍”（[HA](https://docs.crunchybridge.com/concepts/high-availability)、[套餐](https://docs.crunchybridge.com/concepts/plans-pricing)）。**Snowflake Postgres** 于 2026 年 2 月 24 日正式可用，运行 16 到 18，提供 10 天 PITR，但其管理员“不是完整的 Postgres 超级用户”（[Snowflake](https://docs.snowflake.com/en/user-guide/snowflake-postgres/about)、[角色](https://docs.snowflake.com/en/user-guide/snowflake-postgres/postgres-roles)）。
>
> **Aiven。**运行在各大云上的虚拟机，提供 13 到 18，上游结束支持时相应版本也退役（[Aiven](https://aiven.io/docs/platform/reference/eol-for-major-versions)）；Business 有一个备库，Premium 有两个（[Aiven](https://aiven.io/docs/products/postgresql/concepts/high-availability)）。“除少数例外，无法安装仅超级用户可用或不受信任的扩展”；按套餐保留 2 到 30 天的备份（[Aiven](https://aiven.io/docs/products/postgresql/concepts/pg-backups)）；有免费档（[Aiven](https://aiven.io/pricing/postgresql)）。
>
> **EDB Postgres AI Cloud Service。**EDB“将不再向新客户提供 Hosted Cloud Service 选项”；继续提供在客户自己的云账户中管理集群的服务（[EDB](https://www.enterprisedb.com/docs/edb-postgres-ai/cloud-service/)）。Advanced Server 现名为“Enterprise Postgres (Oracle Compatible)”（[EDB](https://www.enterprisedb.com/docs/epas/latest/)），每 vCPU 小时的价格是社区 PostgreSQL 的三倍（[EDB](https://www.enterprisedb.com/docs/edb-postgres-ai/cloud-service/references/pricing_and_billing/)）；它的 Oracle 功能无法迁移到社区 Postgres。
>
> **Fly.io Managed Postgres。**每个套餐都包括“一个主库和副本、PgBouncer 和备份”，提供 16 和 17，容量最高 1 TB（[Fly.io](https://docs.fly.io/postgres)）；Fly.io 将“安全补丁和版本升级”列为“开发中”。旧的非托管 Fly Postgres“已不再维护”（[Fly.io](https://docs.fly.io/unmanaged-postgres/index.md)）。
>
> **PlanetScale Postgres。**2025 年 9 月 22 日正式可用：一个主库和两个副本跨可用区部署，可使用本地 NVMe（“Metal”）或网络存储，提供 17 和 18（[正式发布](https://planetscale.com/blog/planetscale-for-postgres-is-generally-available)、[版本](https://planetscale.com/docs/postgres/cluster-configuration/versions)），通过逻辑复制提供 CDC（[PlanetScale](https://planetscale.com/docs/postgres/integrations/logical-cdc)）。Metal“存储容量由实例大小固定”；备份默认“保留 2 天”（[PlanetScale](https://planetscale.com/docs/postgres/backups/point-in-time-recovery)）；Neki 分片“目前处于 Platform Preview”（[PlanetScale](https://planetscale.com/docs/postgres/sharding)）；按集群大小定价（[PlanetScale](https://planetscale.com/pricing)）。
>
> **Tiger Cloud。**“Timescale 现已更名为 Tiger Data”（2025 年 6 月 17 日，[Tiger Data](https://www.tigerdata.com/blog/timescale-becomes-tigerdata)）：在 16 到 18 上运行 TimescaleDB（[Tiger Data](https://www.tigerdata.com/docs/deploy/tiger-cloud/tiger-cloud-aws/upgrades)），面向超出[建模一章](/15-models/#basics-chapter-15)中 BRIN 和分区能力范围的事件数据。“Tiger Cloud 不提供超级用户访问”（[Tiger Data](https://www.tigerdata.com/docs/deploy/tiger-cloud/tiger-cloud-aws/security/read-only-role)）；PITR 为 3 或 14 天；按计算小时加存储收费（[Tiger Data](https://www.tigerdata.com/pricing)）。
>
> **DigitalOcean。**提供 14 到 18（[DigitalOcean](https://docs.digitalocean.com/products/databases/postgresql/details/limits/)），PITR 可回到“过去七天内”（[DigitalOcean](https://docs.digitalocean.com/products/databases/postgresql/details/features/)），没有超级用户。对新账户自 2026 年 10 月 15 日起，对全部账户自 11 月 30 日起，新建的 Standard Edition 集群“不能使用超过 4 GiB 内存的套餐，也不能添加备库或只读节点”；高可用移到更贵的 Advanced Edition。
>
> **Render。**提供 13 到 18（[Render](https://render.com/docs/postgresql-upgrading)）；高可用由异步备库在 30 秒后接管（[Render](https://render.com/docs/postgresql-high-availability)），这[可能丢失最后几笔提交](/38-replication/#asynchronous-is-the-default-and-it-can-lose-commits)；PITR 为 3 或 7 天（[Render](https://render.com/docs/postgresql-backups)）；免费数据库“创建 30 天后到期”（[Render](https://render.com/docs/free)）。
>
> **Heroku Postgres。**Advanced 档采用“计算与存储解耦”架构，容量最高 100 TB，目前处于“有限正式可用”阶段（[Heroku](https://devcenter.heroku.com/articles/heroku-postgres-plans)、[Advanced](https://devcenter.heroku.com/articles/heroku-postgres-advanced)）；默认版本为 18（[Heroku](https://devcenter.heroku.com/articles/heroku-postgres-version-support)）。所有者“比超级用户低一级”（[Heroku](https://devcenter.heroku.com/articles/heroku-postgresql-credentials)）；故障切换可能丢失“少量但有明确上限的最近已提交数据”（[Heroku](https://devcenter.heroku.com/articles/heroku-postgres-ha)）。2026 年 2 月 6 日，Heroku 表示正在“转向以维护为主的工程模式……而不是引入新功能”（[Heroku](https://www.heroku.com/blog/an-update-on-heroku/)）。

## 无服务器平台围绕开发者的日常工作优化 {#serverless-platforms-optimize-for-the-developers-day}

它们的卖点是：数据库空闲时不花钱，每个拉取请求都能创建一个分支，有时还提供围绕数据库的一整套后端。代价是冷启动、难以预测的按单位用量计费，以及在平台套装中，应用更多部分与同一家厂商绑定。

<span id="neon-supabase-xata-nile-and-railway-entry-by-entry" class="pgbasics-deep-dive-anchor" data-td-print-local></span><span id="basics-35-neon-supabase-xata-nile-and-railway-entry-by-entry" class="pgbasics-deep-dive-anchor"></span>

> [!DETAILS]- 深入阅读：逐一查看 Neon、Supabase、Xata、Nile 和 Railway
>
> 截至 2026 年 10 月：
>
> **Neon。**计算与存储由“一条预写式日志（WAL）记录流”连接，现在以 Lakebase Postgres 为品牌（[Neon](https://neon.com/docs/introduction/architecture-overview)）；Databricks 于 2025 年 5 月 14 日宣布计划收购 Neon，而 Neon“已是 Databricks 平台的一部分”（[Databricks](https://www.databricks.com/company/newsroom/press-releases/databricks-agrees-acquire-neon-help-developers-deliver-ai-systems)）。提供 14 到 18（[Neon](https://neon.com/docs/postgresql/postgres-version-policy)）。空闲 5 分钟后缩容至零，“几百毫秒内”唤醒（[Neon](https://neon.com/docs/introduction/scale-to-zero)）；可“从当前或过去的状态”创建分支（[Neon](https://neon.com/docs/introduction/branching)）；恢复窗口按套餐最长为 30 天。大版本升级意味着新建项目；保持连接的逻辑复制订阅者会使计算实例保持唤醒，非活动的复制槽约 40 小时后会被删除（[Neon](https://neon.com/docs/guides/logical-replication-neon)）。按计算单元小时计费，有免费套餐（[Neon](https://neon.com/docs/introduction/plans)）。
>
> **Supabase。**每个项目一个 Postgres 实例，配上一套平台服务：Auth、通过 PostgREST 提供的 REST API、Realtime、Storage 和 Edge Functions（[Supabase](https://supabase.com/docs/guides/getting-started/architecture)），运行 PostgreSQL 15 或 17（[Supabase](https://supabase.com/docs/guides/platform/upgrading)）。基于[行级安全](/33-security/#basics-chapter-33)构建，有文档说明如何通过逻辑复制向外传输数据（[Supabase](https://supabase.com/docs/guides/database/postgres/setup-replication-external)）。分支“默认不含数据”（[Supabase](https://supabase.com/docs/guides/deployment/branching)）；PITR 是附加服务，至少需要 Small 计算规格；无需清理的存储引擎 OrioleDB“处于公开测试阶段”（[Supabase](https://supabase.com/docs/guides/database/orioledb)）。套餐加计算加用量计费（[Supabase](https://supabase.com/pricing)）。
>
> **Xata。**“原生支持分支的 Postgres”：每个分支都是“底层逻辑卷的写时复制快照”（[Xata](https://xata.io/docs/core-concepts/branching)），支持匿名化克隆；提供 14 到 18（[Xata](https://xata.io/docs/platform/extensions)）；可运行在 Xata 的云、你的云，或自托管环境中（[Xata](https://xata.io/pricing)）。只能原地进行小版本升级；Xata 的公开文档没有描述备份或 PITR。
>
> **Nile。**面向多租户 SaaS 的 Postgres：每个存储页属于一个租户，租户可以放在共享或专用计算实例上（[Nile](https://www.thenile.dev/docs/getting-started/architecture)），也就是[分片一章](/40-sharding/#basics-chapter-40)里手动完成的事情。只提供 PostgreSQL 15，而且租户表上不支持用户定义函数、触发器和序列（[Nile](https://www.thenile.dev/docs/postgres/postgres-compatibility)）。
>
> **Railway。**不是托管服务：它的模板是“非托管服务”，备份、调优、安全和监控“由你负责”（[Railway](https://docs.railway.com/databases)）。可选 Patroni 高可用（[Railway](https://docs.railway.com/databases/postgresql-ha)）；备份是卷快照，并非基于 WAL 的恢复（[Railway](https://docs.railway.com/volumes/backups)）。
>
> 还有规模更小的服务，例如按操作次数计费的 Prisma Postgres（[Prisma](https://www.prisma.io/docs/postgres/faq)）。

## 自行管理，超级用户和值班电话都归你 {#self-managing-gives-you-the-superuser-and-the-pager}

在虚拟机或 Kubernetes 上自行管理，意味着你有超级用户、能用所有扩展、可以在发布当天使用任意版本，而且在规模大且稳定时成本最低。代价是值班轮换，[复制](/38-replication/#dont-hand-roll-failover)和[备份](/32-backups/#test-your-restores)章节中的所有工作都归你。标准组件是用 Patroni 做高可用，用 pgBackRest、WAL-G 或 Barman 做备份，在 Kubernetes 上使用 CloudNativePG 等 Operator。

<span id="the-self-managed-toolkit-with-licenses" class="pgbasics-deep-dive-anchor" data-td-print-local></span><span id="basics-35-the-self-managed-toolkit-with-licenses" class="pgbasics-deep-dive-anchor"></span>

> [!DETAILS]- 深入阅读：自行管理的工具箱及其许可证
>
> 截至 2026 年 10 月：
>
> - **Patroni：**“一个用于构建 PostgreSQL 高可用（HA）集群的 Python 模板”，用 etcd、Consul、ZooKeeper 或 Kubernetes 进行领导者选举；MIT，支持 PostgreSQL 9.3 到 18（[GitHub](https://github.com/patroni/patroni)）。
> - **pgBackRest：**向 S3、Azure 或兼容 GCS 的存储执行全量、差异和增量备份，支持 PITR（[pgbackrest.org](https://pgbackrest.org/)）。维护者于 2026 年 4 月 27 日宣布“不再维护”，随后在 5 月 18 日宣布“一个赞助商联盟已联合起来，资助后续开发”（[新闻](https://pgbackrest.org/news.html)）。
> - **WAL-G**（Apache-2.0）和 **Barman**（GPL-3.0）（[WAL-G](https://github.com/wal-g/wal-g)、[Barman](https://pgbarman.org/)）。
> - **CloudNativePG：**一个“直接与 Kubernetes API 集成”而不使用 Patroni 的 Operator；Apache-2.0，自 2025 年 1 月起成为 CNCF Sandbox 项目，通过其 Barman Cloud 插件执行备份（[GitHub](https://github.com/cloudnative-pg/cloudnative-pg)、[CNCF](https://www.cncf.io/projects/cloudnativepg/)）。
> - **Crunchy Postgres for Kubernetes（PGO）：**Patroni 加 pgBackRest，Apache-2.0；其默认镜像受 Crunchy Data Developer Program 条款约束，所以先读这些条款（[GitHub](https://github.com/CrunchyData/postgres-operator)）。
> - **Zalando postgres-operator：**通过 Spilo 镜像使用 Patroni，MIT，支持 PostgreSQL 14 到 18（[GitHub](https://github.com/zalando/postgres-operator)）。
> - **StackGres：**AGPL-3.0，基于 Patroni，带有 Web 控制台和大量扩展（[StackGres](https://stackgres.io/)）。**Percona Operator for PostgreSQL**“基于 Crunchy Data 开发的 Postgres Operator”，Apache-2.0（[GitHub](https://github.com/percona/percona-postgresql-operator)）。

## 超级用户权限和保留期限可以排除一批服务 {#superuser-access-and-retention-rule-services-out}

下面把主要服务列在一张表中，时间截至 2026 年 10 月，来源见各服务条目。“版本”指新建数据库可选的大版本。重点看那些能帮你排除服务的列：只有一家给你超级用户，备份保留期限则从两天到五周不等。

| 服务 | 形态 | 版本 | 超级用户 | PITR 窗口 |
|---|---|---|---|---|
| RDS | 传统 | 14 到 18 | 无 | 0 到 35 天 |
| Aurora | 存算分离 | 14 到 18 | 无 | 1 到 35 天 |
| Cloud SQL | 传统 | 9.6 到 18 | 无 | 7 或 35 天 |
| AlloyDB | 存算分离 | 14 到 18 | 无 | 1 到 35 天 |
| Azure | 传统 | 14 到 18 | 无 | 7 到 35 天 |
| Crunchy Bridge | 传统 | 15 到 18 | 有 | 10 天 |
| PlanetScale | NVMe 或网络 | 17、18 | 无 | 默认 2 天 |
| Neon | 无服务器 | 14 到 18 | 无 | 最长 30 天 |
| Supabase | 套装 | 15、17 | 无 | 附加服务 |

<span id="tbl-35-2"></span>

**Table 35-2.** 超级用户权限和保留期限可以排除一批服务


Supabase 的每个套餐都有每日备份；时间点恢复是附加服务。Azure 仍然为现有服务器运行 11 到 13，但属于付费延长支持。

## 用排除法选择 {#choose-by-elimination}

按顺序回答这些问题。前几个答案就会排除列表中的大多数服务。

1. **多大，增长多快？**检查存储上限（Fly.io Managed Postgres 为 1 TB，RDS 和 Azure 为 64 TiB，Aurora 为 256 TiB）、磁盘是否与实例大小绑定，以及你的工作集与能负担的内存之间的关系。
2. **写入多少？**写入关注提交延迟和 WAL 量；读取关注副本和缓存未命中。
3. **需要超级用户或某个特定扩展吗？**核对确切版本和[脚注](/34-managed/#extensions-come-from-an-allowlist)。需要超级用户，选项就缩小到 Crunchy Bridge、你自己的容器，或自行管理。
4. **有什么合规要求？**认证和数据驻留情况随服务商和地域而异。索要报告，不要只看一墙的标志。
5. **哪个地域？**应用所在的地域。跨地域往返会抵消本书中其他一切优化（[往返的成本比查询更高](/03-latency/#round-trips-cost-more-than-queries)）。
6. **RPO 和 RTO 是多少？**[先写下来](/32-backups/#write-down-rpo-and-rto-first)：异步高可用可能丢失最近的提交，2 天的 PITR 窗口也无法挽回第 3 天才发现的错误。
7. **采用哪种预算模型？**固定实例的费用可预测；按用量计费的计算资源空闲时便宜、忙碌时可能令人意外；按 I/O 定价的存储会让你为缺失的索引付费。
8. **如何离开？**签约前先回答下一节的问题。

我们的看法是：今天起步的大多数团队，选择应用所在云上的传统托管服务，并配置足够内存容纳工作集，就能用得很好。只有能明确说出本地 NVMe、存算分离或无服务器替你解决什么问题时，再去选择它们。

## 在需要退出之前规划退出 {#plan-the-exit-before-you-need-it}

每个服务商都让迁出成为可能，但很少有服务商让它变得容易。成本取决于你的系统有多少部分使用了 PostgreSQL 之外的东西。

### 社区 Postgres 能干净地迁走 {#community-postgres-moves-cleanly}

只要坚持使用社区 PostgreSQL 和社区扩展，模式、数据、角色（大部分）和 SQL 都能跟你走。有两条迁移路径。

**`pg_dump`**（[pg_dump](https://www.postgresql.org/docs/18/app-pgdump.html)）在哪里都能工作，但在它所需的数小时内，数据库要么只读，要么两边的数据开始分歧（[逻辑备份](/32-backups/#pg_dump-is-portable-small-and-slow-to-restore)）；角色可能需要脚本处理，因为 `pg_dumpall` 需要超级用户。

**逻辑复制，然后切换**（[逻辑复制](/38-replication/#logical-replication-copies-rows-not-pages)），只需停机几分钟而不是几小时，前提是原服务商允许你发布数据。RDS、Aurora、Cloud SQL、AlloyDB（通过 pglogical）、Azure、Neon、Supabase 和 PlanetScale 都有相应文档；注意它的[限制](/38-replication/#logical-replication-skips-ddl-and-sequences)。

### 专有存储、功能和配套集成带不走 {#proprietary-storage-features-and-glue-stay-behind}

- **专有存储。**Aurora、AlloyDB 和 HorizonDB 在你带不走的存储上运行 Postgres，只能通过逻辑方式迁出。AlloyDB Omni 是部分例外，它把同一套引擎授权给你在自己的机器上运行。Neon 的存储是开源的，但自行运行它本身就是一项工程。
- **专有功能。**EDB 的 Oracle 兼容语法、AlloyDB 用于分析的列式引擎、Aurora 的 Babelfish（SQL Server 协议兼容），以及 Aurora Limitless Database 的分片表。使用它们没有问题，但每一项都要计为将来重做的工作。
- **平台服务。**Supabase Auth、Storage 和自动生成的 API；Heroku 的附加服务集成；Nile 按租户存储的模型。数据可以用 `pg_dump` 导出，围绕它构建的应用却不能。
- **服务商扩展、角色和配套集成。**某家服务专属的扩展、`rds_superuser` 之类的角色、仪表盘、IAM 认证、私有网络、备份策略。这些不是代码，却要花数周来处理。

### 留好退路 {#keep-the-door-open}

- **坚持使用社区 PostgreSQL 功能**，除非某项专有功能值得付出退出成本，并且要把这个决定写下来。
- **定期进行逻辑导出**，存到服务商账户无法删除的位置，每季度在别处恢复一次。这样既演练了退出，也获得了[经过验证的备份](/32-backups/#test-your-restores)。
- **现在就检查发布支持：**让一台由你控制的原生 PostgreSQL 服务器订阅预发布环境。
- **保持大版本更新。**每个大版本支持五年：13 于 2025 年 11 月 13 日结束支持，14 将于 2026 年 11 月 12 日结束支持（[PostgreSQL](https://www.postgresql.org/support/versioning/)）。延长支持会向落后的版本收费，而较新的版本会让你有更多迁移去处。

## 本章要点 {#the-short-version}

- 在缓冲区缓存之上，各服务商运行的是同一个 PostgreSQL。在它之下，一旦工作集超过内存，页面的位置就会主导基准测试结果。
- 网络存储每次未命中都要一次往返，但不会随主机故障消失；本地 NVMe 每次读取要快得多，却会随主机一起消失。
- 把每个公开基准测试都视作厂商公布的结果，并用自己的查询跑自己的测试。
- 为更快的存储而迁移之前，先证明读取占主导：对比工作集与内存，检查 `IO` 等待和 `shared_blks_read`。先修查询，再加内存。
- 超大规模云厂商胜在覆盖面，专业服务商胜在专注 Postgres，无服务器平台胜在空闲成本和分支。选定之前，找出各家文档中的限制。
- 依次按数据大小、写入量、扩展与超级用户需求、合规、地域、RPO 与 RTO，以及预算模型进行选择。
- 提前规划退出：能向外进行逻辑复制，定期执行由你控制的 `pg_dump`，并列出所依赖的全部专有功能。

## 延伸阅读 {#further-reading}

- [Amazon EBS volume types](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html)，AWS 文档。各类网络卷的 IOPS、吞吐量、延迟和持久性。
- [Amazon EBS-optimized instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html)，AWS 文档。往往最先限制性能的各实例存储性能上限与突发窗口。
- [Data persistence for instance store volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-store-lifetime.html)，AWS 文档。本地 NVMe 数据究竟在什么时候消失。
- [Benchmarking Postgres](https://planetscale.com/blog/benchmarking-postgres)，PlanetScale 博客。最常被引用的服务商对比背后的方法；阅读时要带上前面提到的注意事项。
- [Reaction to the PlanetScale PostgreSQL benchmarks](https://xata.io/blog/reaction-to-the-planetscale-postgresql-benchmarks)，Xata 博客。竞争对手对同一方法的批评，以及支持高速网络存储的论据。
- [sysbench-tpcc README](https://github.com/Percona-Lab/sysbench-tpcc)，Percona。按作者自己的说法，这个最常用的类 TPCC 脚本是什么，又不是什么。
- [Logical replication](https://www.postgresql.org/docs/18/logical-replication.html)，PostgreSQL 文档。选择任何服务商时都应核对的退出路径。
- [Versioning policy](https://www.postgresql.org/support/versioning/)，PostgreSQL。每个大版本五年；各服务商的支持日程都依赖这些日期。