PostgreSQL基准测试：AWS RDS vs 自托管Hetzner（2026）

背景

2026 年 7 月，一篇来自 Hacker News 的技术文章引发了广泛讨论。该文章对三种常见的小型 PostgreSQL 生产部署方案——AWS RDS、Hostim（一家欧洲托管服务商）以及自托管在 Hetzner 裸金属/VPS——进行了同配置、同负载的基准测试。测试旨在回答一个经典问题：当数据库规模被锁定在 2 vCPU / 4 GB RAM 时，托管服务与自托管方案在性能、延迟、成本和可用性方面的实际差距有多大？文章作者强调，单纯比较列表价（listed price）会严重误导决策，因为 AWS 的真实账单远高于标价，而高可用（HA）架构会彻底改写对比结论。

核心内容

测试对象与配置

所有测试均运行于中欧区域，PostgreSQL 16，数据库大小统一为 2 vCPU / 4 GB RAM。对比了三类方案：

• AWS RDS：实例类型 db.t4g.medium（ARM Graviton 处理器，可突发性能），单可用区（Single-AZ）。
• Hostim：计费方案为 drp-50（50 欧元/月），包含自动故障转移的副本节点，默认启用复制。
• Hetzner 自托管：一台 2 vCPU / 4 GB 的 VPS，运行默认配置的 PostgreSQL（shared_buffers = 128 MB，无调优），单节点无复制。

测试方法与工作量

测试工具为 pgbench，数据集大小为 scale factor 50（约 750 MB，可完全装入内存，因此测试主要衡量 CPU 和提交路径性能，而非冷磁盘读取）。针对每个目标数据库，使用一台独立的 4 vCPU 客户端（与数据库位于同一区域，确保网络一跳可达）运行以下基准：

• 写入负载（TPC-B 模式）：4 个并发连接，运行 300 秒。
• 只读负载：8 个并发连接，300 秒。
• 单连接写入延迟：1 个连接，60 秒，用于隔离提交路径和 fsync 延迟。

网络延迟分别通过 TCP ping（nping --tcp -p 5432）和 SELECT 1 往返时间测量，以避免 ICMP 被拦截带来的误差。

性能结果

所有运行均零失败事务。

| 测试项 | 结果 | |---|---| | 写入吞吐量（4 客户端，TPC-B） | Hostim 约为 AWS RDS 的 2.5 倍，约为 Hetzner 自托管默认配置的 2.1 倍。 | | 单连接写入延迟（1 客户端） | 该项衡量提交路径的 WAL 刷新延迟（synchronous_commit 默认开启），本质上是存储 fsync 延迟。自托管节点和 AWS RDS 均使用网络附加块存储（EBS、Ceph 等），这是写入差距的最大原因。Hostim 的本地存储延迟显著更低。 | | 读取吞吐量（8 客户端，仅 SELECT） | Hetzner 自托管最快（得益于原始 CPU 单核性能和直接访问），Hostim 与 RDS 接近，RDS 最慢。注意 db.t4g.medium 是可突发实例，在 300 秒持续运行中可能耗尽 CPU 积分，降级到基线性能（这正是该实例层级的设计行为）。如果工作负载需要持续 CPU 性能，应升级到 m 系实例，成本约翻倍。 |

网络延迟

SELECT 1 往返时间：Hetzner 自托管 < Hostim < AWS RDS。具体数值原文未给出，但趋势明确。

实际价格：列表价只是冰山一角

AWS RDS 的 ~$48/月（单可用区，按需）仅仅是实例费用。除此之外，AWS 按量计费的项目包括：

• 存储：gp3 按 GB-月计费；若选择 Provisioned IOPS（io1/io2），则按 IOPS-月收费（例如 3000 IOPS 的 io1 约 $300/月）。
• IOPS 和吞吐量：超出 gp3 基线的部分另收费。
• 备份：超出卷大小的备份存储按 GB 计费。
• 数据传输：出站流量和跨可用区流量按 GB 计费。

原文举例：在创建数据库向导中，如果将存储类型从 gp3 切换到 Provisioned IOPS SSD，系统默认会预置 3000 IOPS，这会使月账单额外增加约 $300（io1 约 $0.10/IOPS，io2 约 $0.125/IOPS）。同一个数据库，仅仅因为一个下拉菜单的选择，月成本就能相差 ~$300。因此，$48 只是一个地板价，而非实际价格。

高可用性（HA）如何改变对比

上述基准测试均基于单节点。但生产环境通常需要高可用，而这一点会彻底改变成本对比：

• Hostim drp-50：默认包含一个备用节点和自动故障转移，无需额外配置。€50/月已包含 HA。
• AWS RDS：要获得备用节点和自动故障转移，需启用 Multi-AZ。Multi-AZ 会启动第二个实例（成本约翻倍），并且由于写入需要等待同步备库确认，使写入变得更慢（比单 AZ 结果更差）。因此，公平的 HA-to-HA 对比下，RDS 的写入性能将低于上面测得的单 AZ 数据。
• Hetzner 自托管：单节点无故障转移。要匹配 Hostim，需要再买一台 VPS（约 €20/月），然后自行搭建复制（Streaming Replication + Patroni/repMgr 等工具），并自行管理路由、故障检测和事故响应。这变成一个运维项目。

将所有方案归一化到“包含自动故障转移的复制型 PostgreSQL”后，实际对比如下：

• Hostim：€50/月，性能如上（写入最快，读取中等）。
• AWS RDS：实例费 ~$48×2 + 存储+IOP S+ 备份+ 流量，写入更慢。
• Hetzner 自托管：€20+20（两个 VPS）+ 运维时间成本（无价）。

限制与说明

• db.t4g.medium 是可突发 ARM 实例，持续运行会触发 CPU 积分基线，这是该价格层级的正常行为，非配置错误。
• 自托管使用了 PostgreSQL 默认配置（未加 shared_buffers 等调优），这是为了模拟“开箱即用”的基线。调优会提升其性能，但调优工作属于自托管的隐性成本。
• RDS 基准测试采用单 AZ；Multi-AZ 会更慢更贵。
• 数据集完全在 RAM 中（scale 50），排除了冷存储对结果的影响。如果数据集大于 RAM，存储延迟缺口会进一步拉大写入差距。
• 架构不同：RDS 是 ARM Graviton，另两者是 x86。这是各提供商在该价格点提供的实际硬件，因此报告时未刻意统一。

核心结论

• 对于写入密集型工作负载（此规模下），Hostim 因为存储 fsync 延迟更低而显著领先。
• 对于读取密集型工作负载，愿意调优并自行运维的话，Hetzner 自托管具备原始 CPU 优势。
• AWS RDS 在同等价格层级下写入和读取均是最慢或接近最慢，且真实成本（存储、IOPS、出站流量、Multi-AZ）是列表实例价的数倍。
• 如果你需要复制型 PostgreSQL 但不想自己搭建，包含 HA 的固定价格（如 Hostim 的 €50/月）才是正确的比较基准，而非单节点标价。

关键要点

• 性能排名：写入吞吐量：Hostim >> 自托管 >> RDS；读取吞吐量：自托管 > Hostim ≈ RDS。单连接写入延迟：Hostim 最优，自托管和 RDS 因依赖网络附加存储而明显