Aurora Compute Units (ACU) benchmarks

AWS will not provide benchmark results, because every customer's workload is different. Also, the mapping of ACU to performance will change because AWS continuously iterates to improve its services, leading to changes in the underlying implementation (e.g. move from Intel to AMD or ARM).

This document for Aurora Serverless here - https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.how-it-works.html

States that

Each ACU is a combination of approximately 2 gigabytes (GB) of memory, corresponding CPU, and networking.

Aurora Serverless v1 manages the warm pool of resources in an AWS Region to minimize scaling time. When Aurora Serverless v1 adds new resources to the Aurora DB cluster, it uses the router fleet to switch active client connections to the new resources.

The appropriate approach to determine "performance per ACU" is by benchmarking, e.g. using sysbench. Please refer to this blog post for how to proceed: https://aws.amazon.com/blogs/database/running-sysbench-on-rds-mysql-rds-mariadb-and-amazon-aurora-mysql-via-ssl-tls/

I did a quick sysbench run using a 5.8GB data set (100 tables, each of 250K rows) with the oltp_read_only.lua benchmark. Note that these results are not in any way "official" numbers or validated by AWS. Also, these results are for Aurora MySQL, but a similar approach should work for Aurora PostgreSQL, and are "quick and dirty" - a rigorous benchmark would have dozens or hundreds of test runs for each test case, to quantify variability.

With this data size, the entire data set fits in memory and there is no IO bottleneck since the benchmark is all reads, so this is primarily a CPU/memory benchmark.

The following command was used to create the sample data (the assumption is an "sbtest" database has already been created):

sysbench /usr/share/sysbench/oltp_read_write.lua --threads=32 --mysql-host=XXXX.ap-southeast-1.rds.amazonaws.com --mysql-user=XXX --mysql-password='XXX' --mysql-port=3306 --tables=100 --table-size=250000 prepare

The load test was then run using an m5.2xlarge EC2 instance (8 vCPU, 32GB RAM) as the load generator, with the following command:

sysbench /usr/share/sysbench/oltp_read_only.lua --threads=96 --events=0 --time=600 --mysql-host=XXXX.ap-southeast-1.rds.amazonaws.com --mysql-user=XXX --mysql-password='XXX' --mysql-port=3306 --tables=100 --table-size=250000 --range_selects=off --db-ps-mode=disable --report-interval=10 run

Here are my results (note that I had to increase the number of connections/threads to 192 in some of the benchmark runs):

There appears to be a scaling inflection point between 8 ACU and 16 ACU; I have also seen this with provisioned Aurora at large instance sizes.

As always, YMMV. A more realistic benchmark that includes inserts, updates, and deletes (e.g. sysbench oltp_read_write.lua) should be executed, to investigate IO performance.