AWS 上 PostgreSQL 性能与成本深度基准测试：23 种 EC2 实例类型全解析

通过 1GB 数据集、32 并发、90% 读负载的基准测试，找出 AWS EC2 上运行 PostgreSQL 的性价比最优实例配置。

一、引言

在 AWS 上部署 PostgreSQL 时，开发者面临一个经典难题：如何在满足性能需求的同时最小化成本？EC2 实例类型繁多，从通用型 (m 系列) 到计算优化型 (c 系列)、内存优化型 (r 系列)，再到突发性能型 (t 系列)，加上 x86-64 和 Arm64 (Graviton) 两种架构，以及 gp3 磁盘的不同配置（基线吞吐 vs 最大吞吐），选择空间极为庞大。

本文作者通过系统化的基准测试，在统一的工作负载下测量了 23 种实例类型 × 2 种磁盘配置（共 52 种组合）上 PostgreSQL 17 的实际表现，并给出了清晰的选择建议。测试区域为 us-east-1，采用按需定价。

二、测试方法与核心指标

2.1 工作负载

• 读写比例：90% 读取 / 10% 写入（典型的 OLTP 读密集场景）
• 并发数：32 个并发连接
• 数据集大小：1 GB（所有实例均使用相同数据集，确保公平比较）
• 数据库版本：PostgreSQL 17
• 目标吞吐量：33,000 RPS（每秒请求数）—— 这是作者设定的性能“及格线”

2.2 关键评估指标

• RPS (Requests Per Second)：每秒完成的事务请求数，衡量吞吐能力
• RPS/$：每美元成本可获得的 RPS，衡量性价比
• 延迟 (avg ms / p95 ms / p99 ms)：平均、95 分位、99 分位延迟
• Headroom：实际 RPS 与目标 RPS (33,000) 的比值，例如 1.4× 表示有 40% 的性能余量
• RPS/vCPU 和 RPS/GiB：单位计算与内存资源的效率

2.3 磁盘配置：gp3-baseline vs gp3-max

AWS EBS gp3 卷提供可配置的基线吞吐和突发吞吐。测试中每个实例都测试了两种配置：

• gp3-baseline：使用 gp3 卷的默认基线 IOPS/吞吐（通常为 3000 IOPS / 125 MB/s）
• gp3-max：将 gp3 卷配置为最大性能（16000 IOPS / 1000 MB/s），但成本也相应增加

三、核心发现：谁是最优解？

3.1 最佳性价比选择

在所有 52 种配置中，满足 33,000 RPS 目标的最便宜配置是：

m8g.large (Graviton) + gp3-baseline

• 月成本：~$82/月
• 实际 RPS：45,515（目标的 1.4×，即 40% 余量）
• 延迟：平均 0.70ms，p95 2.02ms，p99 2.76ms
• 架构：Arm64 (Graviton)

这一结果令人瞩目：一个 2 vCPU、8 GiB 内存 的相对小型实例，仅用基线 gp3 磁盘，就能轻松胜任 33,000 RPS 的负载，且成本极低。

3.2 最佳 RPS/$ 效率

如果纯粹追求每美元的吞吐效率，胜出者是：

c8i.large (x86-64) + gp3-baseline

• RPS/$：451,476（每美元每小时可获得 451,476 次请求）
• 实际 RPS：52,203（目标的 1.6×）
• 月成本：~$84/月
• 延迟：平均 0.61ms，p95 2.16ms，p99 2.79ms

c8i 系列是 Intel 最新一代计算优化实例，其 RPS/$ 效率甚至超过 Graviton 实例，但成本略高。

3.3 性能与成本边界

作者绘制了成本/性能前沿曲线（cost/performance frontier），即不同价位上能获得的最高 RPS。核心趋势：

• 在低预算区间（<$100/月），m8g.large 和 c8i.large 统治了性价比前沿
• 在中预算区间（$100-$300/月），m8g.xlarge、c7i.xlarge、r8g.xlarge 等是主要竞争者
• 高预算区间（>$300/月），m8g.2xlarge 和 c8i.2xlarge 提供最高绝对性能，但边际收益递减

四、详细基准数据解析（52 种配置全览）

以下按 RPS/$ 降序排列，展示所有测试配置的核心数据（为节省篇幅，仅列出关键行）：

4.1 顶级性价比组（RPS/$ > 300,000）

实例	架构	磁盘	vCPU	内存	RPS	RPS/$	月成本	延迟(avg)	Headroom
c8i.large	x86-64	gp3-baseline	2	4 GiB	52,203	451,476	~$84	0.61ms	1.6×
m8g.large	arm64	gp3-baseline	2	8 GiB	45,515	407,555	~$82	0.70ms	1.4×
m8g.xlarge	arm64	gp3-baseline	4	16 GiB	70,871	351,826	~$147	0.45ms	2.1×
m7i.large	x86-64	gp3-baseline	2	8 GiB	41,305	336,586	~$90	0.77ms	1.3×
m7g.xlarge	arm64	gp3-baseline	4	16 GiB	58,726	317,234	~$135	0.54ms	1.8×

关键观察：

• c8i.large 虽然只有 4 GiB 内存，但凭借 Intel 最新 Sapphire Rapids 架构和更高的时钟频率，RPS 反而超过内存翻倍的 m8g.large
• Graviton 实例 (m8g, m7g) 在 RPS/$ 上紧随其后，且具有更低的内存延迟（p95 2.02ms vs 2.16ms）
• m8g.xlarge 的 Headroom 高达 2.1×，适合未来业务增长预留空间

4.2 中端性价比组（RPS/$ 200,000 - 300,000）

实例	架构	磁盘	RPS	RPS/$	月成本	Headroom
r8g.large	arm64	gp3-baseline	38,531	304,746	~$92	1.2×
m7i.xlarge	x86-64	gp3-baseline	65,582	293,410	~$163	2.0×
r8g.xlarge	arm64	gp3-baseline	64,627	279,821	~$169	2.0×
m8g.medium	arm64	gp3-baseline	16,670	249,555	~$49	0.5×
m7g.large	arm64	gp3-baseline	24,669	238,304	~$76	0.7×

关键观察：

• r8g 系列（内存优化）虽然内存更大，但在 1GB 数据集下并未带来额外性能收益——因为数据集完全可放入任何实例的内存中，内存不再是瓶颈
• m8g.medium 和 m7g.large 的 Headroom 低于 1.0×，意味着无法满足 33,000 RPS 目标，但适合更低负载场景
• m7i.xlarge 提供 2.0× 余量，适合对稳定性要求较高的生产环境

4.3 高性价比组（RPS/$ 150,000 - 200,000）

实例	架构	磁盘	RPS	RPS/$	月成本	Headroom
c8i.xlarge	x86-64	gp3-max	69,067	199,429	~$253	2.1×
m8g.xlarge	arm64	gp3-max	67,428	199,242	~$247	2.0×
r8g.xlarge	arm64	gp3-max	69,292	188,322	~$269	2.1×
m5.xlarge	x86-64	gp3-baseline	39,959	186,794	~$156	1.2×
m7g.xlarge	arm64	gp3-max	57,738	179,252	~$235	1.7×

关键观察：

• 当使用 gp3-max 磁盘时，RPS 相比基线版本提升有限（通常 5-15%），但成本增加显著（磁盘成本翻倍甚至更多）
• m5.xlarge 是上一代实例（Intel Skylake/Cascade Lake），性价比已落后于 m7i 和 c8i
• 对于 1GB 数据集，磁盘性能并非瓶颈，因此 gp3-max 的收益很小

4.4 中低性价比组（RPS/$ 100,000 - 150,000）

实例	架构	磁盘	RPS	RPS/$	月成本	Headroom
m7g.2xlarge	arm64	gp3-baseline	77,197	221,629	~$254	2.3×
m8g.2xlarge	arm64	gp3-baseline	81,451	213,807	~$278	2.5×
c8i.2xlarge	x86-64	gp3-baseline	61,861	155,916	~$290	1.9×
m5.2xlarge	x86-64	gp3-baseline	51,445	126,737	~$296	1.6×

关键观察：

• 2xlarge 实例的 RPS/vCPU 效率下降明显（m8g.2xlarge 的 RPS/vCPU 为 10,181，而 m8g.large 为 22,757），说明 PostgreSQL 在超过 4 vCPU 后扩展性开始衰减
• m8g.2xlarge 提供最高的绝对 RPS (81,451) 和最大的 Headroom (2.5×)，但成本也最高

4.5 低性价比组（RPS/$ < 100,000）—— 突发性能实例 (t 系列)

实例	架构	磁盘	RPS	RPS/$	月成本	Headroom
t3.small	x86-64	gp3-baseline	3,353	78,486	~$31	0.1×
t4g.small	arm64	gp3-baseline	2,842	73,413	~$28	0.1×
t4g.medium	arm64	gp3-baseline	3,394	61,132	~$41	0.1×
t4g.large	arm64	gp3-baseline	5,157	57,870	~$65	0.2×
t3.medium	x86-64	gp3-baseline	3,401	53,551	~$46	0.1×

关键观察：

• t 系列（突发性能实例）的 RPS 极低，仅为 3,000-5,000，远不及 33,000 目标
• 高延迟：p95 延迟超过 50ms，p99 超过 60ms，不适合生产级数据库
• 但成本极低（$28-$77/月），适合开发、测试或极低负载场景
• 重要警告：t 系列依赖 CPU 积分，一旦积分耗尽，性能会大幅下降。持续 32 并发负载会导致积分迅速耗尽

五、深度分析与工程启示

5.1 架构之争：Graviton (Arm64) vs x86-64

• 性价比：在相同价位段，Graviton 实例通常提供更高的 RPS/$（例如 m8g.large vs c8i.large，Graviton 月成本低 $2，但 RPS 低 13%）
• 延迟：Graviton 的 p95 延迟略优（2.02ms vs 2.16ms），但差异很小
• RPS/vCPU 效率：x86-64 实例的单 vCPU 吞吐更高（c8i.large 的 26,102 vs m8g.large 的 22,757），说明 Intel 的每核性能仍占优
• 结论：对于 PostgreSQL，如果预算敏感且能接受 Arm 生态，Graviton 是更经济的选择；如果需要绝对单核性能，x86-64 仍有优势

5.2 磁盘配置：基线 vs 最大吞吐

• 在 1GB 数据集下（完全可缓存在内存中），gp3-max 相比 gp3-baseline 的 RPS 提升不超过 15%
• 但成本增加显著：gp3-max 的磁盘成本是基线的 2-3 倍
• 结论：对于内存可容纳的数据集，基线 gp3 已足够。只有数据集远超内存大小、需要大量磁盘 I/O 时，才应考虑 gp3-max

5.3 实例系列选择指南

场景	推荐实例系列	理由
极致性价比	m8g (Graviton)	最低成本满足目标，余量充足
极致 RPS/$	c8i (x86-64)	每美元吞吐最高
内存敏感型	r8g (Graviton)	大数据集时内存优势显现
开发/测试	t4g (Graviton)	成本极低，但不要用于生产
高余量需求	m8g.2xlarge	2.5× 余量，适合业务快速增长

5.4 注意事项与局限性

1. 数据集大小：本测试仅使用 1GB 数据集。作者的工具支持 10GB、50GB 数据集，更大数据集下结果可能不同（磁盘 I/O 会成为瓶颈）
2. 工作负载特征：90% 读 / 10% 写是 OLTP 典型场景。写密集或复杂查询场景下，结果会显著变化
3. 按需定价：未考虑预留实例、Spot 实例或 Savings Plans 的折扣，实际成本可能降低 30-70%
4. PostgreSQL 配置：使用默认配置，未针对特定实例进行调优。实际部署时应调整 shared_buffers、work_mem 等参数
5. 单区域：仅测试 us-east-1，其他区域定价和性能可能不同

六、如何自己使用这个工具？

作者提供了一个交互式 Web 工具（https://postgres.saneengineer.com），你可以：

1. 选择数据集大小（1GB、10GB、50GB）
2. 设定目标吞吐量（RPS）
3. 查看所有实例配置是否满足要求
4. 交互式排序和筛选表格
5. 自动高亮显示满足目标的最便宜配置

工具还提供了完整的原始基准数据 CSV 下载，供进一步分析。

七、总结

对于 33,000 RPS 的 PostgreSQL 读密集负载，AWS 上最经济的选择是 m8g.large (Graviton) + gp3-baseline，月成本仅 $82，且拥有 40% 的性能余量。如果追求极致性价比，c8i.large (x86-64) + gp3-baseline 以 $84/月的成本提供更高的 RPS/$。

核心教训：

• 不要盲目选择大实例——m8g.large 这种 2 vCPU 的小实例就能胜任很多场景
• 磁盘性能不是瓶颈——除非数据集远超内存，否则基线 gp3 足够
• Graviton 是性价比之王——但 x86-64 在单核性能上仍有优势
• t 系列不适合数据库——延迟高、性能不稳定，仅适合开发测试

原文链接：https://postgres.saneengineer.com