多年来，我们专注于构建快速的系统。ClickHouse就是这种专注的一个例子。性能并不是我们后期添加的一个特性，它是从一开始就设定的核心设计目标。在构建我们的托管Postgres服务时，我们采用了类似的方法。结果是为我们的客户提供了最快的托管Postgres服务之一。Postgres处理事务工作负载，而ClickHouse处理分析工作负载。这两者结合形成了一个统一的数据堆栈，为“最佳的”基础SaaS和AI应用程序提供支持。有鉴于此，以我们评估ClickHouse的方式来评估它，进行一个公开的、可重现的基准测试，感觉非常自然。这就是我们构建PostgresBench的原因，它是一个用于比较托管Postgres服务的基准测试。ClickBench是一个被广泛引用的OLAP基准测试。它使用透明和可重现的方法对超过40个数据库进行基准测试。所有查询、数据集和结果都是公开的，任何人都可以验证这些数字或提交改进。PostgresBench对事务性的Postgres工作负载应用相同的方法论。规则很简单：使用一个被广泛理解的标准工作负载，在测试的所有服务中保持基础设施一致，发布所有配置以便结果可以被重现，允许任何人提交结果或标记问题。如果某个数字看起来不正确，可以进行检查。如果某个配置不公平，可以进行修正。这就是重点。PostgresBench基于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个线程运行了每次基准测试，这反映了生产 transaction 工作负载的现实并发性。每次运行持续10分钟，时间足够长，可以突破预热阶段并捕获稳定的吞吐量。我们测试了两个规模因子：6849（约100GB）和34247（约500GB）。这些对应于实际Postgres部署的典型数据集大小：一个是应用程序刚刚启动，快速增长，并且工作集合理地适合缓存，另一个是已经达到合理规模，正在增长，并且工作集开始溢出到磁盘。两个规模下结果之间的差距可以告诉你有关服务如何处理数据增长时存储压力的一些有用信息。我们报告每个配置的平均TPS、平均延迟、P95延迟和P99延迟，所有三个运行都公布排名，且每个单独运行的详细信息可在代码库中找到。没有基准测试是完全中性的。每一个选择，从实例类型到Postgres配置，都可能使一个系统优于另一个。我们在下面解释每个决定背后的思考，并在基准测试代码库中详细记录每个系统的确切设置以及结果。我们在us-east-2区域提供了一个16 vCPU、64 GB的实例来运行基准测试客户端，确保客户端永远不是瓶颈。所有服务都在同一区域进行测试，因此结果反映的仅是数据库性能，而不是跨区域的网络延迟。我们也不通过可用区将客户端和数据库合并，因为并不是所有服务都提供这种能力。然而，为了确保对提供这种能力的服务的公平性，这是我们将来可能考虑添加的内容。欢迎贡献。对于大多数服务，我们以1:4的CPU与RAM比例为目标，并测试了两种大小：4 vCPUs/16GB RAM和16 vCPUs/64GB RAM。Aurora没有提供提供该比例的实例类型，因此我们在两种大小下使用了1:8的比例：4 vCPUs/32 GB RAM和16 vCPUs/128 GB RAM。我们对所有支持它们的服务使用了带有NVMe缓存的Graviton实例，包括AWS RDS和Aurora。这样即使在这些情况下，竞争者也拥有相同的硬件优势，尽管在这些情况下NVMe是用作缓存，而不是主要存储。虽然所有服务都提供高可用性，但底层架构各不相同。有些使用备用复制，其他使用共享或分布式存储层。由于我们专注于单节点计算和存储性能，因此我们在没有启用HA的情况下进行测试，以使其隔离。我们可能在未来将HA配置作为一个单独的维度添加。我们没有修改各服务的默认PostgreSQL配置；每个系统都使用其开箱即用的设置进行测试。这反映了典型用户的行为，其中大多数