PostgresBench 重磅发布！可复现基准测试，衡量 Postgres 服务真实性能
Lionel Palacin约 10 分钟本文字数：5920；估计阅读时间：15 分钟
作者：Lionel Palacin
Meetup活动
ClickHouse 上海第3届 Meetup 火热报名中，详见文末海报！
多年来，我们一直专注于构建高速系统。ClickHouse 正是这种专注的体现。性能并非事后才添加的功能，而是从一开始就确立的核心设计目标。
在构建 我们的托管 Postgres 服务 时，我们也采用了类似的方法。由此我们得以向客户提供业内领先的托管 Postgres 服务。Postgres 负责事务性工作负载，而 ClickHouse 则处理分析性工作负载。它们共同构成一个统一的数据栈，为 SaaS 和 AI 应用奠定“ 最佳实践 ”基础。
基于此考量，我们自然而然地选择以评估 ClickHouse 的方式来对其进行评估：通过公开、可重现的基准测试。
正因如此，我们创建了 PostgresBench，一个旨在对比各类托管 Postgres 服务的基准测试工具。
ClickBench 是一个被广泛引用的 OLAP 基准测试工具。它采用透明且可复现的方法，对 40 多个数据库进行基准测试。所有查询、数据集和测试结果均公开可查，任何人都可以验证数据或提交改进建议。
PostgresBench 将同样的方法论应用于事务性 Postgres 工作负载。其规则非常直接：
• 采用公认的标准工作负载
• 确保所有受测服务的基础设施配置一致
• 公布所有配置，以确保结果可复现
• 允许任何人提交测试结果或指出潜在问题
如果数据看起来有误，可以随时进行核查。如果配置存在不公平之处，可以及时修正。这正是其核心意义所在。
工作负载
PostgresBench 基于 pgbench 构建，而 pgbench 是 标准的 Postgres 基准测试工具。我们使用其开箱即用的、类似于 TPC-B 的工作负载，该工作负载模拟了频繁写入和更新的短时并发事务。它合理地代表了常见的事务模式：支付、订单处理、库存更新以及其他以小型、频繁写入方式对数据库造成高负载的工作场景。
我们特意选择了 pgbench。sysbench 和 Percona TPCC 等工具最初是为 MySQL 工作负载设计的。对于 Postgres 基准测试而言，pgbench 更为贴切，并且它随 Postgres 内置，这使得任何人无需额外工具即可轻松复现结果。
运行参数
每次基准测试运行使用以下参数：
pgbench -c 256 -j 16 -T 600 -M prepared -P 30 \
-s $SCALE_FACTOR \
-h $PGHOST -p $PGPORT -U $PGUSER -d $PGDATABASE
我们使用 256 个客户端和 16 个线程运行了每次基准测试，这反映了生产事务工作负载的实际并发水平。每次运行持续 10 分钟，足以度过预热期并捕获稳定的吞吐量。
我们测试了两种规模因子：6849（约 100 GB）和 34247（约 500 GB）。这些规模对应于真实 Postgres 部署中典型的数据集大小：其中一种情况是应用程序刚启动，数据量快速增长，工作集仍能合理地容纳在缓存中；另一种情况是应用程序已达到相当规模，数据量持续增长，工作集开始溢出到磁盘。这两种规模下结果之间的差距，能有效地揭示服务如何应对数据增长带来的存储压力。
捕获的指标
我们报告了每个配置三次运行的平均 TPS、平均延迟、P95 延迟和 P99 延迟。我们公布了最佳和最差运行的排名，每次运行的详细数据都可在仓库中查阅。
没有基准测试是完全中立的。从实例类型到 Postgres 配置，每一个选择都可能使某个系统获得优势，而牺牲另一个系统。我们将在下面解释每个决定背后的思考，并在基准测试仓库中，连同测试结果一并记录了每个系统使用的确切设置。
客户端机器设置
我们在美国东部 2 区 (us-east-2 region) 部署了一个 16 vCPU、64 GB 的实例来运行基准测试客户端，其配置确保客户端不会成为性能瓶颈。所有服务都在同一区域进行测试，因此结果仅反映数据库性能，而非跨区域网络延迟。我们也没有按可用区将客户端和数据库部署在同一区域，因为并非所有服务都提供此功能。然而，为确保对支持此功能的服务的公平性，我们未来可能会考虑增加此项配置。欢迎贡献。
实例选择
对于大多数服务，我们设定了 1:4 的 CPU-RAM 比率目标，并测试了两种规格：4 vCPU/16GB RAM 和 16 vCPU/64GB RAM。由于 Aurora 不提供符合此比率的实例类型，我们采用了 1:8 的比率，同样测试了两种规格：4 vCPU/32 GB RAM 和 16 vCPU/128 GB RAM。
对于所有支持 Graviton 实例 的服务（包括 AWS RDS 和 Aurora），我们均启用了带 NVMe 缓存的 Graviton 实例。即便在这些场景中 NVMe 被用作缓存而非主存储，此举仍能确保其他竞品享有同等的硬件优势。
单节点
尽管所有服务都提供高可用性 (HA)，但其底层架构各异。有些采用主备复制，有些则使用共享或分布式存储层。由于本次测试重点关注单节点的计算和存储性能，我们禁用了 HA 功能进行测试以确保性能隔离。未来我们可能会将 HA 配置作为一个单独的维度纳入考量。
默认 Postgres 配置
我们不修改各服务的默认 PostgreSQL 配置，每个系统都使用其开箱即用的设置进行测试。这反映了典型的用户行为，即大多数用户期望无需调优即可获得良好性能。未来我们可能会将 Postgres 配置作为一个额外的考量维度。
关于定价的说明
我们本次并未进行定价比较。因为在测试时，由 ClickHouse 管理的 Postgres 尚未发布。我们预计其定价在相同硬件配置下会具有竞争力，一旦该服务可用，您将能够根据此处的结果推断出其性价比。
包含的系统
PostgresBench 的首次发布涵盖了五项服务，每项服务均在两种实例配置下进行了测试：一个较小的 4 vCPU / 16 GB 配置和一个较大的 16 vCPU / 64 GB 配置（或等效配置）。这使我们能够观察各项服务如何随着资源增加而扩展，而不仅仅是其在单一配置下的性能表现。
所有服务均在 us-east-2 区域进行测试，且禁用了 HA 功能，使用的 Postgres 版本为 17 或 18，具体取决于各提供商的支持情况。在本次测试中，Aurora 是首批测试服务中唯一仍使用 Postgres 17 的服务。
结果
相同的脚本在所有系统上运行相同的基准测试。每次运行都在隔离环境中进行，机器或数据库上没有其他并发进程运行。下方是结果汇总表。所有结果均可在 PostgresBench 上查阅。
规模因子 6849 (约 100 GB)
规模因子 34247 (约 500 GB)
TPC-B 工作负载混合了读写操作，并由于持续的 DML (UPDATE) 活动生成 WAL 记录，因此可能成为 I/O 密集型。这种模式在快速增长的 OLTP 工作负载中尤为典型，其中持续的写入活动会驱动 WAL 的生成，从而使磁盘性能成为影响 Postgres 性能的关键因素。
ClickHouse 托管的 Postgres 采用与计算资源物理共置的 NVMe 存储作为后端。这使得磁盘访问延迟能达到微秒级而非毫秒级，并且能提供持续高 IOPS，这些 IOPS 既不跨租户共享，也不受网络带宽限制。因此，与基于共享存储（如 EBS 或对象存储）的架构相比，它能提供显著更优的性能，同时不牺牲 可用性 或 持久性。
相比之下，EBS 支持的卷等替代方案会将网络延迟引入 I/O 路径。尽管读取操作可能受益于内核页缓存，但每次 fsync 调用（包括事务提交）都必须由远程存储层进行确认。对于本基准测试中使用的这类写入密集型工作负载，每次提交的开销会迅速累积，并直接影响整体性能。
TL;DR: 大多数情况下，Postgres 并不慢，而是你的存储性能不足。敬请关注，我们很快将对这一主题进行更深入的技术探讨。
下图展示了磁盘密集型工作负载在从传统 Postgres 迁移至 NVMe 存储支持的 Postgres 后，其 P99 延迟的显著降低。
对于主要受磁盘 IOPS 和延迟瓶颈限制的 Postgres 工作负载，这种架构差异是决定性因素。基准测试结果也直接印证了这一点。
完整的基准测试仓库已开源。
每次运行都发布结构化 JSON，这意味着结果不仅可以直观比较，还可以通过编程方式进行比较。该仓库包含了运行基准测试的脚本以及所有原始结果。如果配置不正确或对任何服务造成不公平的优势，相关方可在公开环境下进行审查和纠正。
该仓库可在 github.com/ClickHouse/PostgresBench 访问。
提交结果
若要在您自己的实例上运行基准测试，只需执行此命令即可。运行时间约为 30 到 40 分钟。
# Set connection parameters
export PGHOST="your-database-host"
export PGPORT=5432
export PGUSER="postgres"
export PGPASSWORD="your-password"
export PGDATABASE="postgres"
# Required: instance hardware details
export VCPUS=16
export RAM_GB=64
# Required: instance metadata
export SYSTEM_NAME="Postgres by ClickHouse"
export INSTANCE_TYPE="m8gd.4xlarge"
export INSTANCE_STORAGE="950 GB - NVMe"
export PRIMARY_STORAGE="NVMe"
# Optional: output
export OUT_JSON="results.json" # Output file name (default: oltpbench_result.json)
# Run the benchmark
./run.sh
该脚本负责数据初始化，运行三次基准测试，并将结果写入 JSON 文件。
要添加您的系统：
1. 克隆基准测试仓库
2. 按照文档中描述的基础设施设置，使其与测试实例的规格相匹配
3. 使用已发布的参数运行 run.sh
4. 创建 Pull-Request 以提交您的结果
5. 我们将审核配置并发布结果
PostgresBench 现已上线，所有基准测试结果均已公开，供用户查阅和比较。
有兴趣将您的系统加入到榜单吗？我们欢迎您的贡献！克隆 repository，运行基准测试，提交您的结果，从而帮助其成为最全面的 Postgres 性能参考资料。
好消息：ClickHouse Shanghai User Group第 3 届 Meetup 火热报名中，将于2026年5月16日在上海市浦东新区世纪大道1568号中建大厦33层 Optiver上海举行，扫码免费报名
（温馨提示：因场地登记需要，请实名报名。）
/END/
试用阿里云 ClickHouse企业版
轻松节省30%云资源成本？阿里云数据库ClickHouse 云原生架构全新升级，首次购买ClickHouse企业版计算和存储资源组合，首月消费不超过99.58元（包含最大16CCU+450G OSS用量）了解详情：https://t.aliyun.com/Kz5Z0q9G
征稿启示
面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：[email protected]