In March 2024, Amazon Relational Database Service (Amazon RDS) announced the availability of Provisioned IOPS (input/output operations per second) io2 Block Express volumes for database engines.
Choosing the right storage configuration that meets performance requirements is a common challenge when creating and managing database instances.
With io2 Block Express volumes, your database workloads benefit from consistent sub-millisecond latency, enhanced durability by 100 times over io1 volumes (99.999% for io2 compared to 99.9% for io1), and 20 times more IOPS/GiB from provisioned storage (up to 1,000 IOPS per GiB) at the same price as io1.
In this post, we provide an end-to-end guide for what storage class to choose depending on your use case. In addition, we compare the performance of different storage volumes on open source engines supported by Amazon RDS, to validate them from a database-centric perspective.
Our example benchmark configuration shows that io2 Block Express volumes consistently outperformed gp3 and io1 volumes across database engines and configurations. Compared to gp3, io2 Block Express volumes delivered higher performance with up to 66% lower disk latency and up to 57% higher throughput. When compared to io1, we observed up to 61% lower disk latency and up to 38% higher throughput. This makes io2 Block Express volumes ideal for production workloads that require a sustained number of transactions per second.
Which storage type to choose
Amazon RDS provides several storage types to select from, with varying levels of IOPS, throughput, and scalability. The two main storage types to consider are Provisioned IOPS SSD (io1 and io2 Block Express) and General Purpose SSD (gp2 and gp3). Your workload type and requirements are the key factors to evaluate when choosing the right storage type.
For production databases, which usually have high requirements in terms of latency and performance, io2 Block Express volumes are the current state-of-the-art storage technology.
Production and mission-critical workloads
Mission-critical workloads that handle large volumes of transactions require high IOPS and low latency. For example, if you have a banking application that processes transactions, account information, and financial records, you need consistent performance and the highest possible level of data durability to meet regulatory requirements.
In this scenario, io2 Block Express volumes are the best choice. They are designed to deliver the highest level of performance and durability, making them well-suited for mission-critical applications like banking. They provide up to 256,000 IOPS, which is essential for handling the high IOPS requirements of large transaction volumes.
Furthermore, io2 Block Express volumes offer 99.999% durability, which is the highest level offered by Amazon RDS, and is essential for financial applications, where data integrity and compliance with regulations are of utmost importance.
Similarly, a real-time data analytics application that performs data analysis, reporting, and decision support on large data volumes requires the lowest possible latency. Here, io2 Block Express volumes emerge as the optimal storage option, because they can deliver sustained high IOPS, even at higher queue depths, providing consistently low latency under heavy workloads. These volumes can be provisioned with up to 256,000 IOPS and achieve sub-millisecond latency, outperforming other volume types.
In terms of pricing, io1 volumes and io2 Block Express storage volumes are billed at the same rate, and you can migrate to io2 online with no performance impact during the migration. This means that by migrating from io1 to io2 Block Express, you can get a performance boost at no additional cost.
Non-critical databases: Development and test environments
Non-production databases, such as those used for development, testing, or staging, typically have lower performance requirements compared to production databases. In these scenarios, where the focus is on rapid iteration and validation rather than handling high production traffic, cost-effectiveness of storage often outweighs the need for the highest possible performance, making Amazon RDS with gp3 storage a suitable choice.
On gp3 storage volumes, Amazon RDS provides a baseline storage performance of 3,000 IOPS and 125 MiBps. For striped volumes, Amazon RDS provides a baseline storage performance of 12,000 IOPS and 500 MiBps, with the possibility of provisioning up to 64,000 IOPS and 4,000 MiBps, making them suitable for most non-production workloads. They also offer 99.9% durability and single-digit millisecond latency 99% of the time.
Amazon RDS also offers gp2 volumes, the previous generation general purpose volume type. However, gp2 IOPS performance is dependent on the volume size, which means that volumes smaller than 4 TiB have limited I/O performance capabilities compared to gp3. Additionally, gp2 provides burst performance for limited amounts of time, which would lead to inconsistent read/write performance, and it could be challenging to predict and manage the performance characteristics of these volumes.
gp3 volumes address the limitations of gp2 volumes because you can provision additional IOPS and throughput above the baseline IOPS and throughput that are included, independent of the volume size. This provides more predictable and consistent performance, making it straightforward to match the storage performance with your application’s requirements.
Given these advantages, it’s recommended to migrate existing gp2 volumes to gp3.
Benefits of migrating to io2 Block Express
The major benefit of io2 Block Express volumes is sub-millisecond latency performance with much less variability compared to the other storage types. This is important for applications that require consistent response times.
Other benefits include:
- Throughput capacity up to 1,000 MiBps per volume (4,000 MiBps if it’s striped in four physical volumes). This allows handling high volumes of data.
- Durability (99.999%) higher than io1 and other storage types (99.9%).
- Possibility to provision up to 256,000 IOPS independently of database size.
In summary, io2 Block Express volumes offer higher performance, lower latency, higher throughput, and more reliable and consistent workload handling.
The following table summarizes the main characteristics of the different storage types.
| io2 Block Express | io1 | gp3 | gp2 | |
| Latency | Sub-millisecond | Single-digit millisecond | Single-digit millisecond | Single-digit millisecond |
| Max IOPS | 256,000 | 256,000* | 64,000** | 64,000** |
| Max Throughput (MiBps) | 16,000° | 4,000°° | 4,000°° | 1,000°°° |
| Durability | 99.999% | 99.9% | 99.9% | 99.9% |
* Max 64,000 for Amazon RDS for SQL Server
** Max 16,000 for Amazon RDS for SQL Server
° Max 4,000 for Amazon RDS for SQL Server
°° Max 1,000 for Amazon RDS for SQL Server
°°° Max 250 for Amazon RDS for SQL Server
Benchmark tools and setup
We ran Amazon RDS benchmarks on open source engines supported by Amazon RDS and AWS Graviton, and compared the results between storage volumes in the us-west-2 AWS Region.
We tested on Amazon RDS for MySQL 8.0.35 and Amazon RDS for PostgreSQL 16.1 in Single-AZ and Multi-AZ with a db.r6gd.4xlarge instance.
The study was conducted using both sysbench and HammerDB to run non-cached benchmark tests and gather results respectively on latency and throughput. Sysbench is a scriptable multi-threaded open source tool based on LuaJIT, which provides a collection of OLTP-like database benchmarks. HammerDB is an open source database load testing and benchmarking tool, used to create a test schema, load it with data, and simulate the workload of multiple virtual users against the database for both transactional and analytic scenarios.
We used an Amazon Elastic Compute Cloud (Amazon EC2) client instance (m6i.16xlarge) to launch the test sessions. We chose a 16xlarge instance to avoid potential bottlenecks related to network bandwidth, CPU, or memory.
Storage size and IOPS were kept the same across the different storage types (gp3, io1, and io2 Block Express) for a fair comparison.
We limited IOPS to 20,000 to match the maximum that the chosen RDS instance can deliver.
We set the following non-default parameters to maximize storage performance:
- PostgreSQL:
max_wal_sizeSingle-AZ/Multi-AZ: 102,400 (100 GB WAL size); to reduce overhead due to writing the WAL logforce_ssl: 0; to remove connection encryption variable from the tests
- MySQL:
innodb_read_io_threads: 8; to increase parallelizationinnodb_write_io_threads: 8; to increase parallelizationinnodb_io_capacity: 1,000; to benefit from the provisioned IOPSinnodb_io_capacity_max: 5,000; to benefit from the provisioned IOPSinnodb_log_file_size: 21,474,836,480 (20 GB log size); to reduce overhead due to writing the loginnodb_sync_array_size: 1,024; to increase concurrency
The following table lists a comprehensive view of the analyzed configurations.
| Engine | Instance Class | Type | Size (GiB) | IOPS |
| PostgreSQL | db.r6gd.4xlarge | io1 | 6,000 | 20,000 |
| PostgreSQL | db.r6gd.4xlarge | io2 | 6,000 | 20,000 |
| PostgreSQL | db.r6gd.4xlarge | gp3 | 6,000 | 20,000 |
| MySQL | db.r6gd.4xlarge | io1 | 6,000 | 20,000 |
| MySQL | db.r6gd.4xlarge | io2 | 6,000 | 20,000 |
| MySQL | db.r6gd.4xlarge | gp3 | 6,000 | 20,000 |
The max throughput is 4,000 MiBps in each case.
Benchmark latency results
We used sysbench to run latency benchmarks, and in every test, io2 Block Express shows lower latency compared to gp3 and io1. We considered two different latencies:
- Transaction latency – This refers to the time it takes for a single transaction to complete, from the moment it is submitted to the database until it is committed or rolled back. It includes the time spent on various tasks, such as parsing and optimizing the SQL query, acquiring locks on the required database objects, and performing the necessary reads and writes to the database.
- Disk latency – This refers to the time it takes for the database system to read from or write to the storage volume. It is a measure of the performance of the storage subsystem.
Results reported are the average of three iterations.
The following graphs show that the RDS for PostgreSQL instance db.r6gd.4xlarge in Single-AZ configured with io2 Block Express has a 32% improvement over gp3 and 29% over io1 in transaction latency. Regarding disk latency, io2 Block Express shows a 65% improvement over gp3 and 61% over io1.
In a Multi-AZ configuration, io2 Block Express has a 47% improvement over gp3 and 7% over io1 in transaction latency, and a 45% improvement over gp3 and 34% over io1 in disk latency.
Considering Amazon RDS for MySQL, the instance db.r6gd.4xlarge in Single-AZ configured with io2 Block Express has a 33% improvement over gp3 and 27% over io1 in transaction latency. Regarding disk latency, io2 Block Express shows a 66% improvement over gp3 and 61% over io1.
Finally, Amazon RDS for MySQL in a Multi-AZ configuration with io2 Block Express has a 30% improvement over gp3 and 26% over io1 in transaction latency, and a 47% improvement over gp3 and 42% over io1 in disk latency.
Benchmark throughput results
We used HammerDB to run throughput benchmarks. Once again, in each test, io2 Block Express demonstrated better and more consistent performance compared to gp3 and io1. This advantage persisted until hitting the performance plateau, which occurs as the number of virtual users increases to the point where it reaches the maximum number of IOPS that the RDS instance size can provide. Performance is measured in new orders per minute (NOPM) and is reported as the average of five iterations (five different instances) with a ramp-up of 10 minutes and a runtime of 20 minutes. Databases were not reloaded between the virtual users’ scale-up.
The following graphs show that the RDS for PostgreSQL instance db.r6gd.4xlarge in Single-AZ configured with io2 Block Express has better performance, up to 43% compared to gp3 and up to 13% compared to io1 depending on the number of virtual users until hitting the performance plateau.
The same instance in a Multi-AZ configuration has better performance, up to 57% compared to gp3 and up to 23% compared to io1.
The RDS for MySQL instance db.r6gd.4xlarge in Single-AZ configured with io2 Block Express has even better performance, up to 56% compared to gp3 and up to 38% compared to io1.
The same instance in a Multi-AZ configuration has better performance, up to 34% compared to gp3 and up to 20% compared to io1.
Based on the benchmark results provided, the io2 Block Express storage type outperformed gp3 and io1 volumes for both PostgreSQL and MySQL databases on Amazon RDS, making it ideal for workloads that require a sustained number of transactions per second.
Migrating from io1 to io2 Block Express volumes brings significant benefits. io2 Block Express volumes offer higher performance than the previous io1 option at the same price point. This results in a straightforward performance boost without additional costs. Furthermore, io2 Block Express volumes outperform gp3 volumes and are more suitable for performance-sensitive workloads, making them the optimal choice for production and mission-critical workloads.
Getting started with io2 Block Express in Amazon RDS
You can use the Amazon RDS console to create a new RDS instance configured with an io2 Block Express volume or modify an existing instance with io1, gp2, or gp3 volumes.
The following steps illustrate how to create an RDS for PostgreSQL instance with an io2 Block Express volume:
- On the Amazon RDS console, create a new instance.
- Specify the database engine and version.
- Under Storage, for Storage type, choose Provisioned IOPS SDD (io2).
You can also use the CreateDBInstance or ModifyDBInstance API.
For example, we ran the following AWS Command Line Interface (AWS CLI) command to create the RDS for MySQL instance with an io2 Block Express volume used during benchmarking:
Similarly, you can modify an existing RDS instance to use an io2 Block Express volume:
The --apply-immediately option in the preceding command applies the changes to the DB instance immediately. Removing it applies the changes during the next maintenance window.
After you modify the instance, it goes through a storage optimization state. Further modifications to the instance are deferred until the storage optimization is complete. There is a progress indicator, so you have better visibility into the progress and therefore get an estimated time for the storage optimization to complete.
Before you switch your RDS instance’s storage type, be sure to evaluate how the performance and costs align with your application and workload requirements. Test any modifications prior to production changes. Adjust your provisioned IOPS appropriately after observing real workload patterns.
Conclusion
If you’re using Amazon RDS to run your production workloads, you have many storage volumes to choose from.
Amazon RDS io2 Block Express volumes are designed for your critical database workloads that demand high performance, high throughput, and consistently low latency. io2 Block Express storage has the lowest p99.9 I/O latency and the best outlier latency control among major cloud providers, making it ideal for the most I/O-intensive, mission-critical database workloads.
io2 Block Express supports 99.999% durability, up to 64 TiB volumes, 4,000 MiBps throughput, and up to 256,000 Provisioned IOPS for your most demanding database needs for the same price as Amazon RDS io1 volumes.
Amazon RDS io2 Block Express storage volumes are supported for Amazon RDS database engines and, at the moment of writing, are available in US East (N. Virginia, Ohio), US West (N. California, Oregon), Asia Pacific (Hong Kong, Mumbai, Seoul, Singapore, Sydney, Tokyo), Canada (Central), Europe (Frankfurt, Ireland, London, Stockholm), and Middle East (Bahrain) Regions.
You can create or update a fully managed RDS database with an io2 Block Express volume or modify an existing io1, gp2, or gp3 volume type without downtime from the Amazon RDS console or using the CreateDBInstance or ModifyDBInstance API. To learn more about Amazon RDS storage, refer to Amazon RDS DB instance storage.
About the Authors
Stefano D’Alessio is a Technical Account Manager at AWS focused on relational databases services (Amazon RDS and Amazon Aurora). He works with customers providing guidance and recommendations on their workloads in AWS, using best practices and innovation. Apart from work, he enjoys running and playing tennis and padel.
Francesco Martini is a Technical Account Manager at AWS. 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.
Luiz Verona is a Senior Benchmarking Engineer at AWS, with over 15 years of experience in relational databases supporting high-scale workloads. He specializes in database benchmarking, driving enhancements in the performance and reliability of Amazon RDS. Outside of work, Luiz enjoys spending quality time with his family and engaging in outdoor activities such as hiking, cycling, walking, and running.
Source: Read More
