AWS Database Blog
Powering Amazon RDS with AWS Graviton3: Benchmarks
In April 2023, AWS announced the ability to power Amazon Relational Database Service (Amazon RDS) instances with the AWS Graviton3 processor. AWS Graviton3 was announced in May 2022 and is built using a custom-designed ARM architecture using ARM Neoverse cores, optimized for delivering high performance and energy efficiency. AWS Graviton3 provides up to 25% better compute performance compared to Graviton2.
Customers are evaluating moving their Amazon RDS workloads to AWS Graviton3, but many ask if the performance advantage over AWS Graviton2 can be achieved in a typical relational database management system (RDBMS) workload.
In this post we compare the performances of AWS Graviton2 and AWS Graviton3 instances on open-source engines supported by Amazon RDS, to validate them from a db-centric perspective. Our example benchmark configuration shows that AWS Graviton3-based instances provide up to 27% price/performance improvement (based on on-demand pricing) over Graviton2-based instances on RDS for open-source databases.
Overview
We ran Amazon RDS benchmarks on the latest versions of AWS Graviton-supported engines and compared those benchmarks between different types of database instances powered by AWS Graviton2 and AWS Graviton3 processors in the eu-west-1 region.
We tested on Amazon RDS for MySQL 8.0.32, Amazon RDS for PostgreSQL 15.2, and Amazon RDS for MariaDB 10.6.10 with the following instances.
| db.m6g.xlarge (AWS Graviton2) | db.m7g.xlarge (AWS Graviton3) | |
| vCPU | 4 | 4 |
| Memory (GiB) | 16 | 16 |
Benchmarks and testing framework
We used sysbench to run the benchmarks and gather results. Sysbench is a scriptable multi-threaded open-source tool based on LuaJIT, which provides a collection of OLTP-like database benchmarks.
We used an Amazon Elastic Compute Cloud (Amazon EC2) instance (m6g.4xlarge) to launch the test sessions. We chose a 4xlarge instance to avoid potential bottlenecks related to network bandwidth, CPU, or memory. We ran all the instances in the same Availability Zone to minimize the latency. The setup looked like the following diagram.
Our setup can be replicated manually or by leveraging the AWS CloudFormation template we created. Download the template.
We used the built-in test preparation feature provided by sysbench to create two tables, each with 2 million records. We ran the following script on MySQL and MariaDB instances:
We ran the following script on PostgreSQL instances:
Set up the RDS instances
The next task is to set up the RDS instances on which we launch the benchmarks. For each engine, we created one db.[m6g|m7g].xlarge instance (one for AWS Graviton2 and one for AWS Graviton3 processors).
We used the configuration default values with the following exceptions:
- The same Availability Zone as the EC2 instance to minimize the latency.
- Single-AZ deployment mode.
- An Amazon Elastic Block Store (Amazon EBS) io1 volume with 10,000 provisioned IOPs and 200 GB of storage space. We made this choice to avoid EBS storage becoming a performance bottleneck and 200GB is the minimum storage space required for 10,000 IOPs.
- The
max_prepared_stmt_countparameter set to the maximum allowed value for the MySQL and MariaDB engines. Refer to How do I modify the values of an Amazon RDS DB parameter group for details on how to update it. This allows sysbench to launch the required number of threads.
Benchmark tests
We wanted to keep the database CPU utilization above 99% for the entire 30-minute testing period. For this reason, the sysbench run command ran 300 threads on 2 tables and 2 million records, which means 300 concurrent active connections to the database.
We used the default sysbench operating mode, which iterates over the following queries until it reaches the test timeout: five SELECT queries, two UPDATE queries, one DELETE query, and one INSERT.
We ran the following script on MySQL and MariaDB instances:
We ran the following script on PostgreSQL instances:
We ran the test scripts five times to ensure consistent benchmark results.
Raw performance results
The AWS Graviton3-based instances (db.m7g) performed better than the AWS Graviton2-based instances in all our tests. When looking at queries per second, the db.m7g instance on average ran 29% more queries than db.m6g. The results show that db.m7g provides between 19% and 34% improvement compared to db.m6g, depending on the RDBMS engine.
Latency tests showed a similar trend, with db.m7g showing an average 26% reduction over db.m6g. Comparing db.m7g with db.m6g, the engine-specific results show a 34% latency reduction on MariaDB, a 29% latency reduction on MySQL and a 19% latency reduction on PostgreSQL.
Performance per dollar
Because AWS Graviton3-based instances have a different price compared to AWS Graviton2-based instances, we wanted to see what the price-adjusted performance would be. The following table lists the RDS Single-AZ prices in the eu-west-1 region at the time of writing.
| Engine | Instance Type | Price Per Hour (USD) |
| PostgreSQL | db.m6g.xlarge (AWS Graviton2) | 0.352 |
| PostgreSQL | db.m7g.xlarge (AWS Graviton3) | 0.372 |
| MariaDB | db.m6g.xlarge (AWS Graviton2) | 0.336 |
| MariaDB | db.m7g.xlarge (AWS Graviton3) | 0.372 |
| MySQL | db.m6g.xlarge (AWS Graviton2) | 0.336 |
| MySQL | db.m7g.xlarge (AWS Graviton3) | 0.372 |
We normalize the test results to the price per hour to have fair performance-per-dollar benchmark. db.m6g normalized results are closer to the other instance due to its lower price tag. Still, db.m7g on average ran 22% more queries than db.m6g. The price/performance advantage on db.m6g reached 27% on MariaDB.
The trend remains valid when looking at the average latency. db.m7g delivers the lowest latency per dollar, with a 20% reduction over db.m6g.
Clean up
When you’re finished testing, save the benchmark results and delete the created resources. If you are using the CloudFormation template provided, you can navigate to CloudFormation in the AWS Console, choose the stack (you will have named it when you deployed it), and choose Delete.
Conclusion
If you’re adopting Amazon RDS to run your RDBMS workloads, you have a multitude of instance types to choose from, and the offer is expanding every year.
Graviton3-based instances provide up to a 30% performance improvement and up to a 27% price/performance improvement (based on on-demand pricing) over Graviton2-based instances on RDS for open-source databases depending on database engine, version, and workload.
db.m7g and db.r7g database instances are supported on Amazon RDS for PostgreSQL version 15.2 and higher, 14.3 and higher, and 13.4 and higher, Amazon RDS for MySQL version 8.0.28 and higher, and Amazon RDS for MariaDB version 10.11.4 and higher, 10.6.10 and higher, 10.5.17 and higher, and 10.4.26 and higher. These database instances are now available for Amazon RDS in the following regions: US East (N. Virginia, Ohio), US West (Oregon), Asia Pacific (Mumbai, Singapore, Sydney, Tokyo), and Europe (Frankfurt, Ireland). For complete information on pricing and regional availability, please refer to the Amazon RDS pricing page.
Get started with Amazon RDS.
About the authors
Davide Coccia is a Technical Account Manager at Amazon Web Services focused on helping customers build, deploy, and run secure, resilient, and cost-effective workloads on AWS. He has a background in analytics consulting. Outside of work, he keeps himself busy with running, playing football (aka soccer) and learning any sort of new things.
Stefano D’Alessio is a Technical Account Manager at Amazon Web Services focused on relational Databases Services (Amazon RDS and Aurora). He works with customers providing guidance and recommendations on their workloads in AWS, leveraging best practices and innovation. Apart from work, he enjoys running and playing tennis and padel.
Francesco Martini is a Technical Account Manager at Amazon Web Services. He helps AWS customers build reliable and cost-effective systems and also achieve operational excellence while running workloads on AWS. He is a builder and a technology enthusiast with a background as a full-stack developer. He is passionate about sports in general, especially soccer and tennis.