引言

今天,我们正式推出了 PlanetScale for Postgres。在过去的数月里,我们持续专注于打造全球最佳的 Postgres 体验,其中包括优化性能。

为了确保我们的数据库性能符合高标准,我们需要采用一种标准化、可复现且公平的方法来测量和比较各种选择。我们开发了一款内部工具——Telescope——作为创建、运行和评估基准测试的主要工具。

凭借 Telescope,我们能够为工程师快速反馈产品性能的演变情况,并在开发和调优过程中确保指标符合预期。现在,我们决定将这项工作成果分享给全世界,同时提供工具让其他人也能复现我们的测试。

如果你想直接查看测试结果,可以点击以下链接:

  • PlanetScale vs Amazon Aurora
  • PlanetScale vs Google AlloyDB
  • PlanetScale vs Neon/Lakebase
  • PlanetScale vs Supabase
  • PlanetScale vs CrunchyData
  • PlanetScale vs TigerData
  • PlanetScale vs Heroku Postgres
  • PlanetScale vs Xata

以下是 PlanetScale 与其他 Postgres 供应商的性能对比简要概览:


什么是性能基准测试?

性能基准测试的使用方式往往具有误导性,这适用于所有技术,而不仅仅是数据库。

基准测试的局限性

任何形式的基准测试都存在局限性:

  • 每个组织的 OLTP 工作负载都是独特的,没有任何单一基准测试能够捕捉所有此类数据库的性能特征。
  • 数据规模、冷热数据比、QPS 波动性、模式结构、索引以及其他数百种因素共同决定了你的关系型数据库配置的需求。

你无法仅通过查看一个基准测试结果就准确预测你的工作负载会表现得如何。

基准测试的意义

然而,高质量的基准测试对于解答以下问题非常有用:

  • 延迟:我能多快访问我的数据库?
  • 性能特性:在“典型” OLTP 负载下,数据库表现如何(TPS、QPS 等)?
  • 在高读/写压力下表现:数据库在 IOPS 或缓存压力下能维持怎样的性能?
  • 性价比:实现某一性能门槛的成本如何,与其他选项相比性价比如何?

这是我们在进行基准测试时试图回答的问题,并据此选择了三个主要测试工具:

测试工具:

  1. 延迟测试:简单的查询路径延迟测试,从同一区域的另一个实例重复运行 SELECT 1; 语句。简单有效,用于确定基本查询路径延迟。
  2. TPCC 测试:我们使用 Percona 开发的 TPCC-like 基准测试来回答问题 2~4。具体配置细节将在后续部分提供。
  3. OLTP 只读测试:针对表现最佳的数据库运行 OLTP 只读 sysbench 测试工作负载。这用于隔离读性能(多数 OLTP 工作负载的读操作比例超过 80%)。

公平性

在基准测试过程中,我们将自己的产品与一长名单上的其他云 Postgres 提供商进行了比较。我们力求使比较尽可能公平。

所有公开发布的基准测试均与 PlanetScale 运行在 i8g M-320 实例上的版本进行比较。该实例包括 4vCPUs32GB 内存 和 937GB NVMe SSD 存储。这一实例规格及集群配置代表了真实生产应用中的典型配置,例如高 QPS,支持几千 QPS,同时保持低延迟和高可用性。

PlanetScale 的默认设置是分布在 3 个可用区(AZs) 中的一个主库和两个副本。多可用区配置对提供高可用数据库至关重要,同时副本可以应对显著的读负载。


为竞争产品配置

计算资源:

我们为每个竞争对手的测试实例匹配或超过了 PlanetScale 主库的 vCPU 和 RAM

  • Amazon Aurora、Google AlloyDB 和 CrunchyData 支持 8:1 内存:CPU 比率,我们也完全匹配了这一配置。
  • Supabase、TigerData 和 Neon 仅支持 4:1 内存:CPU 比率。我们选择匹配内存,给予它们的 CPU 配置(PlanetScale 的两倍 CPU 数量)不公平但有利。即使在这种情况下,PlanetScale 仍以较少资源显著超越性能。

存储资源:

所有被对比产品的底层存储均为 网络附加存储(NAS)。其中一些(如 Aurora、Neon 和 AlloyDB)不支持配置特定的 IOPS,也有一些支持(如 Supabase 和 TigerData),我们为其默认设置增加了 IOPS。


基准测试方法

为了实现完全透明,以下是我们基准测试的具体条件:

  • 相同云区域:所有数据库和基准测试机器资源均在同一区域中运行(非 Google 产品为 us-east-1,Google 产品为 us-central1)。
  • 可用区设置:除延迟测试外,我们不保证可用区级别设置,因为许多平台不允许指定数据库节点的 AZ。
  • 标准机器配置
    • AWS 基准测试由 c6a.xlarge(4 vCPUs,8 GB 内存)运行于 us-east-1
    • GCP 基准测试由 e2-standard-4(4 vCPUs,16 GB 内存)运行于 us-central1
  • Postgres 默认配置:除连接数限制和超时修改之外,所有 Postgres 配置均使用平台默认设置,以便基准测试。

测试数据:

  1. CPCC-like 基准测试
    数据生成使用 Percona 的 TPCC 脚本,设置为 TABLES=20 和 SCALE=250,生成约 500GB PostgreSQL 数据库
  2. OLTP 测试
    使用 sysbench 的内置 oltp_read_only 基准测试。
  3. 延迟测试
    简单执行重复 200 次 SELECT 1;,测量每次查询的往返时间。

一个邀请

我们的目标并非误导他人,而是向大家展示运行 Postgres 在 PlanetScale Metal 上所能获得的卓越性能。在我们的测试中,PlanetScale Metal 的 Postgres 性能无疑是最优选择。



Postgres 性能基准测试插图

关注公众号:程序新视界,一个让你软实力、硬技术同步提升的平台

除非注明,否则均为程序新视界原创文章,转载必须以链接形式标明本文链接

本文链接:http://folen.top/2025/09/14/postgres/