Performance Considerations: AWS MySQL Showdown:  RDS vs. Aurora vs. Serverless

‍

Performance is often a primary driver when choosing a database service. RDS MySQL, Aurora, and Aurora Serverless exhibit distinct performance characteristics rooted in their underlying architectures and scaling mechanisms.

‍

Architecture Comparison

RDS MySQL

• Operates on a traditional database architecture deployed on Amazon EC2 instances. Performance is directly tied to the selected DB instance class (vCPU, RAM) and the configured storage type (General Purpose SSD - gp2/gp3, Provisioned IOPS SSD - io1/io2).
• In this model, compute resources and storage I/O capabilities are tightly coupled within the provisioned instance. Scaling typically involves changing the instance size or adjusting storage parameters.

Aurora

• Introduces a fundamental architectural shift by decoupling compute instances from a purpose-built, distributed storage layer. This storage system is log-structured, spans multiple Availability Zones (AZs), and handles tasks like redo log processing, which are traditionally managed by the database engine itself.
• Offloading I/O-intensive operations to this specialized storage layer frees up compute instance resources (CPU, memory) for query processing and transaction handling, forming the basis for many of Aurora's performance claims.

Aurora Serverless v1

• Leverages the same advanced Aurora storage layer but manages compute capacity differently. It automatically scales compute resources up or down based on load, measured in Aurora Capacity Units (ACUs).
• However, scaling in v1 occurred in discrete steps (often doubling capacity) and could involve finding a new "warm" instance to handle the load, potentially introducing noticeable pauses or latency during scaling events.

Aurora Serverless v2

• Also utilizes the Aurora storage architecture but significantly refines the compute scaling model. V2 scales capacity almost instantly (often in fractions of a second) and in much finer-grained increments compared to v1.
• This near-seamless scaling occurs within a user-defined capacity range (minimum and maximum ACUs) and is designed to happen without dropping client connections, minimizing the performance friction associated with scaling events.

The evolution from RDS to Aurora, and then from Serverless v1 to v2, demonstrates a clear progression towards cloud-native database design. Aurora's separation of compute and storage addresses bottlenecks inherent in traditional architectures. While Serverless v1 offered elastic compute, its scaling mechanism had practical limitations. Serverless v2 aims to deliver the elasticity promise more effectively by providing rapid, granular scaling, making it suitable for a broader spectrum of dynamic workloads.

‍

Latency and Throughput

RDS MySQL‍

• Performance is contingent on instance sizing, storage configuration (especially provisioned IOPS for demanding workloads), network bandwidth, and query optimization.
• AWS offers features like RDS Optimized Writes and Optimized Reads on specific instance types, claiming up to 2x write throughput improvement and up to 50% faster query processing, respectively, compared to standard MySQL configurations under certain conditions.
• However, the baseline performance mirrors that of standard MySQL Community Edition running on comparable virtual hardware.

Aurora‍

• AWS consistently markets Aurora as having significantly higher throughput than standard MySQL running on similar hardware, with claims of up to 5 times the throughput.
• This advantage stems from the architectural optimizations, particularly the offloading of I/O operations to the distributed storage layer, reducing write amplification, log processing contention, and network overhead within the database instance.
• This often translates to lower and more consistent latency for transactions, especially under high concurrency.

Aurora Serverless v1/v2‍

• The potential performance of an Aurora Serverless instance at any given moment is equivalent to a provisioned Aurora instance with the same number of ACUs.
• However, the experienced performance can differ due to scaling behavior. Serverless v1's scaling mechanism could lead to temporary latency increases or brief pauses as it adjusted capacity.
• Serverless v2 is explicitly designed to mitigate this, offering near-instantaneous scaling that aims to track workload demands closely with minimal disruption to ongoing transactions.
• The maximum achievable throughput scales directly with the number of active ACUs, up to the configured maximum limit.

Benchmarks: While AWS provides performance claims, specific, independent benchmark results comparing RDS MySQL, Aurora, and Aurora Serverless under identical, realistic workloads are essential for definitive validation. Users should consult AWS performance blogs, whitepapers, and reputable third-party benchmark studies (e.g., using tools like sysbench) for quantitative comparisons relevant to their workload patterns. The provided documentation primarily contains AWS claims rather than detailed third-party benchmark data.

Aurora's design focus is clearly on delivering superior throughput and potentially lower latency compared to RDS MySQL. Serverless v2 endeavors to provide this Aurora-level performance potential in an elastic, pay-per-use model, overcoming the scaling-related performance inconsistencies sometimes observed with v1.

‍

‍

Read and Write Scalability Mechanisms

RDS MySQL:

• Read Scaling: Achieved by creating up to 5 Read Replicas. These replicas use standard asynchronous MySQL replication (either statement-based or row-based, typically row-based with GTIDs). Replication lag can occur, especially under heavy write load on the primary or if the replica resources are insufficient, potentially impacting read consistency. Each replica is an independent database instance with its own storage.
• Write Scaling: Primarily achieved through vertical scaling – increasing the instance size (CPU, RAM, network bandwidth) of the primary instance. Multi-AZ deployments provide high availability but do not scale write capacity.‍

Aurora:

• Read Scaling: Supports up to 15 Aurora Replicas within a cluster. Because all instances in an Aurora cluster (writer and replicas) share the same underlying storage volume, replication lag is significantly reduced, often to milliseconds. Replicas read directly from the shared volume; only redo log streams need to be applied to update the buffer cache, which is far more efficient than transferring and replaying binary logs as in traditional MySQL replication. Aurora provides a cluster reader endpoint that automatically load-balances connections across available replicas, simplifying application configuration.
• Write Scaling: Also relies on vertical scaling of the writer instance. However, due to the offloading of I/O work to the storage layer, an Aurora instance might sustain higher write throughput than an RDS MySQL instance of the same size. Additionally, some Aurora versions support Local Write Forwarding, allowing applications connected to read replicas to issue write statements that are automatically forwarded to the writer instance, simplifying application logic in some scenarios.‍

‍Aurora Serverless v1:

• Read Scaling: Did not support read replicas. All read and write traffic was directed to the single, auto-scaling compute endpoint. Scaling was purely vertical via ACU adjustments.
• Write Scaling: Handled automatically by scaling the ACUs of the single endpoint based on load.

Aurora Serverless v2:

• Read Scaling: Fully supports adding Aurora Replicas to the cluster. These replicas can be either provisioned instances or other Serverless v2 instances, providing flexibility. The cluster reader endpoint functions as it does in provisioned Aurora clusters. Auto-scaling policies can be configured for Serverless v2 read replicas, allowing the read capacity to scale independently based on demand.
• Write Scaling: The writer instance scales its ACUs automatically based on load, similar to v1 but with the improved v2 scaling mechanism.

The shared storage architecture gives Aurora a distinct advantage in read scalability over RDS MySQL, enabling more replicas with substantially lower replication lag and simplified management via the reader endpoint. Serverless v2 inherits these benefits, overcoming a significant limitation of Serverless v1 and making it suitable for read-intensive, scalable applications that also require compute elasticity.

‍

Performance Optimization Features

RDS MySQL‍

Key optimizations include the aforementioned Optimized Writes and Reads available on certain instance types. Users can select storage types tailored to performance needs: gp3 SSD offers baseline IOPS/throughput with the ability to provision more independently of storage size, while io1/io2 SSD provides high, consistent IOPS for demanding I/O-bound workloads. Performance Insights is a crucial tool for identifying and optimizing slow queries and database bottlenecks.

Aurora

Aurora boasts several unique performance features stemming from its architecture:

• Storage Auto-Scaling: The cluster volume automatically grows in 10 GiB increments up to 128 TiB as data is added, eliminating the need for manual storage provisioning and potential downtime for resizing. RDS storage requires manual provisioning and scaling.
• Parallel Query: For certain analytical queries (typically read-only, involving full table scans or large range scans), Aurora can push computation down to the storage layer, utilizing potentially thousands of storage nodes to process data in parallel. This can dramatically speed up specific query types (Available for MySQL 5.7 and 8.0 compatible versions).
• Fast DDL: Some Data Definition Language (DDL) operations, like adding a nullable column instantly, can be performed more quickly than in standard MySQL, reducing impact during schema changes.
• Log Processing & Caching Optimizations: The way Aurora handles logging and caching is optimized for its distributed environment, reducing contention and improving efficiency.
• Performance Insights: Fully supported for detailed performance analysis.
• Aurora I/O-Optimized Configuration: A pricing/performance option designed for extremely I/O-intensive workloads. It eliminates per-request I/O charges in exchange for higher instance and storage costs, potentially offering better performance and cost predictability when I/O operations constitute a large portion (>25%) of the Aurora bill.

Aurora Serverless v1‍

Had fewer tunable parameters compared to provisioned Aurora. Performance Insights was available. Primarily relied on the automatic scaling of ACUs as its main performance lever.

Aurora Serverless v2

• Inherits most of the performance optimization features available in the corresponding provisioned Aurora engine version it runs. This includes support for Parallel Query (if applicable to the engine version), Performance Insights, and the option to use the Aurora I/O-Optimized configuration.
• The granular, near-instant scaling of v2 is itself a significant performance and cost optimization feature compared to v1 or manually managing provisioned instances for variable loads.
• Aurora's custom architecture enables deeper, built-in optimizations like Parallel Query and efficient replication that leverage its distributed nature. RDS MySQL relies more on instance-level tuning, storage choices, and newer features like Optimized Reads/Writes layered onto the standard engine.
• Serverless v2 achieves near feature parity with provisioned Aurora regarding optimizations, making it a more versatile performance option than the simpler Serverless v1.
• The introduction of the I/O-Optimized tier for Aurora (including Serverless v2) provides an important alternative cost-performance model for I/O-bound applications.

‍

Performance Capabilities Summary

‍

‍

For a more detailed discussion with real-world insights, watch our expert-led webinar on "AWS MySQL Showdown: RDS vs. Aurora vs. Serverless". Watch the full webinar here

‍

Explore our comprehensive breakdown of how each AWS MySQL solution stacks up in terms of scalability, architecture, and cost-effectiveness. Read: AWS MySQL Architecture: Amazon RDS vs. Aurora vs. Serverless and Cost Comparison for RDS vs. Aurora vs. Serverless

Need Help Choosing the Right AWS MySQL Setup?

Whether you're running on RDS, Aurora, or exploring Serverless, our experts can help you optimize performance, reduce costs, and scale confidently.

With 800+ clients and deep experience in cloud-native database solutions, Mydbops is trusted by unicorns and startups alike.

Let’s talk about your database journey.