Leveling up Amazon RDS with AWS Graviton4: Benchmarks

In November 2024, AWS introduced the latest evolution of its custom-designed ARM-based processors with Graviton4, delivering significant performance and efficiency improvements for Amazon Relational Database Service (Amazon RDS) for PostgreSQL, MySQL, and MariaDB and Amazon Aurora with PostgreSQL compatibility and with MySQL compatibility. Built on the AWS Nitro System and using the latest DDR5 memory, Graviton4 processors provide an up to 40% performance improvement and up to 29% better price-performance compared to Graviton3-based instances.

This launch introduced the new M8g and R8g instance families, including larger instance sizes up to 48xlarge, offering up to 192 virtual central processing units (vCPUs). These advancements empower customers to manage more demanding workloads while optimizing costs.

In this post, we focus on Amazon RDS for PostgreSQL and compare the performance of the new Graviton4 instances to both Graviton3 and Graviton2. Using benchmarks, we evaluate throughput, latency, and price-performance, showcasing the advantages of Graviton4 for modern database workloads.

Benchmark setup

We benchmarked Amazon RDS for PostgreSQL using Sysbench, a multi-threaded benchmarking tool, to compare the performance of Graviton2 (m6g), Graviton3 (m7g), and Graviton4 (m8g) instances. We conducted the tests on Amazon RDS in the us-east-1 AWS Region under a single Availability Zone deployment mode to minimize latency. We used an Amazon Elastic Compute Cloud (Amazon EC2) m7g.4xlarge instance to run Sysbench, avoiding bottlenecks in CPU, memory, or network bandwidth, ensuring configurations reflected real-world workloads.

The following diagram illustrates the setup:

Database engines tested and instance configurations

We conducted benchmark testing for Amazon RDS for PostgreSQL version 16.3, using three instance types to compare processor generations:

• db.m6g.xlarge – Graviton2
• db.m7g.xlarge – Graviton3
• db.m8g.xlarge – Graviton4

This configuration allowed us to directly compare performance across three generations of AWS Graviton processors using the same instance size and database version. The instance specifications are shown in the following table:

To help ensure accurate and consistent results, we made the following adjustments:

• Storage: Amazon EBS io2 volumes with 10,000 provisioned IOPS and 200 GB storage to avoid storage bottlenecks.
• Latency minimization: We conducted all tests in the same Availability Zone as the EC2 instance.

This setup provided a consistent framework to evaluate the performance offered by Graviton4 for Amazon RDS workloads.

Replicating the benchmark setup

To simplify deployment, we created an AWS CloudFormation template that automates the creation of the entire testing environment, including the RDS for PostgreSQL database, EC2 instance, and required configurations. Download the template.

The CloudFormation stack sets up:

• An RDS DB instance running PostgreSQL 16.3
• An EC2 instance pre-configured with Sysbench for running the tests.
• Proper networking configurations to allow seamless connectivity between instances.

After the resources have been deployed using the CloudFormation template, use the Session Manager URL from the template outputs to connect to the EC2 instance and follow the steps in the next sections to prepare and execute the performance test.

While this post focuses on Amazon RDS for PostgreSQL, the CloudFormation template also supports MySQL and MariaDB. You can easily run the same benchmarking workflow for these engines by selecting the appropriate option when launching the stack.

Preparing the benchmark tests

The prepare command creates and populates the required tables (sbtest1 and sbtest2) with an identical schema containing multiple indexed columns to support transactional queries.

• Tables and Data: Two tables, each with 2 million records.
• Sysbench Script: oltp_read_write.lua (used with the prepare command for table creation and data population).

Use the following commands to prepare the tests on the PostgreSQL database.

sysbench /usr/sysbench/src/lua/oltp_read_write.lua \
--pgsql-host=<pgsql-host> --db-driver=pgsql --pgsql-user=postgres \
--pgsql-password='<pgsql-password>' --pgsql-port=5432 --pgsql-db=sbtest \
--tables=2 --table-size=2000000 prepare

Running the benchmark test

The run command initiates the benchmark test by executing a mix of online transaction processing (OLTP) read and write queries on the pre-populated tables. The 100 concurrent threads simulate a high-load scenario, and the 10-second reporting interval provides real-time performance insights.

• Test duration: 30 minutes (1800 seconds).
• Concurrency: 100 threads (simulating high-concurrency workloads).
• Report interval: 10 seconds.
• Workload: OLTP read-write (mix of SELECT, UPDATE, DELETE, and INSERT queries).
• Sysbench script: oltp_read_write.lua (used with the run command for executing the test workload).

Use the following commands to run the benchmark tests on the PostgreSQL database:

sysbench /usr/sysbench/src/lua/oltp_read_write.lua --threads=100 \
--time=1800 --report-interval=10 --pgsql-host=<host> --db-driver=pgsql \
--pgsql-user=postgres --pgsql-password='<password>' \
--pgsql-port=5432 --pgsql-db=sbtest --tables=2 \
--table-size=2000000 run

Performance results

In our tests, the AWS Graviton4-based instances (m8g) showed consistent and substantial performance improvements over Graviton3 (m7g) and Graviton2 (m6g) for Amazon RDS running PostgreSQL workloads.

When comparing queries per second (QPS), m8g instances outperformed both previous generations, as shown in the following figure.

• m8g delivered a 23% increase in queries per second compared to m7g.
• Compared to m6g, m8g achieved a 41% increase in queries per second.
• m7g outperformed m6g with a 15% increase in queries per second.

Latency tests revealed a similar trend of improvement with Graviton4. In the context of our benchmarks, latency reflects the end-to-end time observed by the Sysbench client for each query, which includes both database processing time and any network latency between the client and the database. Sysbench reports latency as the average response time per query in milliseconds. The results demonstrated that Graviton4-based instances consistently reduced query response times compared to both Graviton3 and Graviton2-based instances, showcasing improved efficiency in handling database workloads:

• Average latency decreased by 19% when comparing m8g to m7g.
• Compared to m6g, m8g reduced latency by 29%.
• m7g improved latency by 13% over m6g.

Price-performance analysis

The AWS Graviton4-based instances tested in this benchmark are priced slightly lower than their Graviton3 counterparts, further enhancing their price-performance ratio. This analysis is based on single-instance configurations deployed in the US East (N. Virginia) Region, with prices accurate as of this writing. The following table summarizes the cost and performance metrics for each instance:

To ensure a fair performance-per-dollar comparison, we normalized the test results based on the hourly cost of each instance. As expected, the Graviton4-based db.m8g instance showed clear advantages in queries per dollar across all three generations.

• m8g processed 23% more queries per dollar than m7g, and 34% more than m6g.
• m7g also improved upon m6g, delivering 9% more queries per dollar.

These results reinforce that Graviton4 provides the best price-performance for Amazon RDS for PostgreSQL among the tested instance classes.

Cleanup

When you’ve finished running your benchmarks and have saved your test results, clean up your AWS resources by deleting the CloudFormation stack. Navigate to CloudFormation in the AWS Management Console, select your benchmark stack, and choose Delete. This will automatically remove all resources that were created for testing, including the RDS DB instances, EC2 instance, and associated configurations.

Conclusion

For Amazon RDS users, Graviton4-based instances provide a compelling option for running relational database workloads. In our tests, Graviton4 delivered 41% higher throughput compared to Graviton2 and 23% compared to Graviton3. In terms of price-performance, Graviton4 showed 34% improvement over Graviton2 and 23% improvement over Graviton3. These results may vary depending on the workload. As announced at launch, Graviton4 offers up to 40% higher performance and up to 29% better price-performance compared to Graviton3-based instances, depending on the database engine, version, and workload.

Graviton4-based instances support Amazon RDS for PostgreSQL, MySQL, and MariaDB across a broad set of engine versions. For PostgreSQL, Graviton4 is supported on versions 17.1 and higher, 16.1 and higher, 15.2 and higher, 14.5 and higher, and 13.8 and higher. For MySQL, Graviton4 is available on version 8.0.32 and higher. For MariaDB, Graviton4 supports versions 11.4.3 and higher, 10.11.7 and higher, 10.6.13 and higher, 10.5.20 and higher, and 10.4.29 and higher. As of this writing, these instances are available in the US East (N. Virginia, Ohio), US West (Oregon), Europe (Frankfurt, Ireland), and AWS GovCloud (US-West). These instances can handle demanding workloads with improved cost efficiency and throughput.

To explore Graviton4-based instances and evaluate their impact on your database workloads, see the Amazon RDS pricing page and documentation for supported versions and regional availability. Start optimizing your Amazon RDS workloads today.

About the authors