MySQL RDS 8.4 vs Amazon Aurora: The Write Scaling and Storage Tradeoff

The release of MySQL 8.4 LTS shifts the baseline for managed database expectations, but upgrading a high-throughput system on AWS requires answering a fundamental architectural question: do you rely on RDS 8.4 with Provisioned IOPS EBS volumes, or move to Amazon Aurora’s distributed storage?

Situation

Historically, the decision between Amazon RDS and Amazon Aurora came down to feature availability and replica lag. If you needed the absolute latest MySQL minor version or relied heavily on specific local storage engines, you stayed on RDS. If you needed sub-10 millisecond read replica lag and crash resilience, you moved to Aurora.

With the stabilization of MySQL 8.4 LTS, AWS offers fully managed RDS 8.4 environments utilizing modern graviton instances and io2 Block Express EBS volumes capable of sub-millisecond latency. At the same time, Aurora has matured its I/O-Optimized tier and Serverless offerings. The boundary between “standard managed database” and “cloud-native distributed database” has blurred in marketing, but remains fiercely distinct in production execution.

The Problem

When a database workload scales from hundreds to tens of thousands of writes per second, the storage architecture dictates the failure mode.

On Amazon RDS for MySQL 8.4, writes are fundamentally bound by the EBS volume queue, network limits of the EC2 instance, and the traditional InnoDB doublewrite buffer physics. Scaling writes means vertically scaling the instance and paying for massive io2 Provisioned IOPS.

On Amazon Aurora, the InnoDB storage engine is torn out and replaced with a distributed, purpose-built storage fleet. The database instance only writes redo log records across the network to six storage nodes. However, because Aurora treats every replicated log record as an IOPS operation (unless using the I/O-Optimized tier), a heavy write workload can generate unexpected storage costs that eclipse the compute bill, and high commit frequencies can trigger network latency bottlenecks.

The core question is: when designing for extreme write scaling, how does the physical storage architecture of RDS 8.4 compare to Aurora, and which bottlenecks are you willing to manage?

RDS 8.4 vs Aurora Write Architectures

flowchart TD
    A[Application Write Workload] --> B[Database Engine]
    B --> C[RDS MySQL 8.4 — Monolithic Storage]
    B --> D[Aurora MySQL — Distributed Storage]
    
    C --> E[InnoDB Buffer Pool]
    E --> F[Doublewrite Buffer]
    F --> G[EBS Volume — Network Attached]
    G --> H[EBS IOPS and Throughput Limits]
    
    D --> I[Redo Log Buffer]
    I --> J[Storage Fleet — 6 Nodes across 3 AZs]
    J --> K[Quorum 4 of 6 Acknowledgment]
    K --> L[Asynchronous Page Materialization]

In Practice

The documented pattern for Amazon RDS relies on the traditional MySQL write path. When a transaction commits in RDS 8.4, InnoDB must flush the redo log to the EBS volume. Background threads continually flush dirty pages from the buffer pool to the doublewrite buffer, and then to the tablespace. AWS’s io2 Block Express EBS volumes handle this exceptionally well, but the physical reality is that the EC2 instance must push entire 16KB pages across the network multiple times. If your application causes high page churn—such as updating large JSON columns or maintaining many secondary indexes—the EBS volume queue length will grow, and write latency will spike.

Amazon Aurora’s architecture bypasses this entirely. As AWS documentation states, Aurora does not flush 16KB data pages from the database instance to storage over the network. It only transmits the redo log records. The distributed storage nodes handle the computational heavy lifting of applying those redo logs to data pages asynchronously. This drastically reduces the network bandwidth required per transaction and eliminates the doublewrite buffer penalty.

However, Aurora’s quorum model means a commit must be acknowledged by 4 out of 6 storage nodes distributed across 3 Availability Zones. While AWS has optimized this path, if the workload involves thousands of tiny, single-row, unbatched commits per second, the sheer volume of network round trips can saturate the writer instance’s network thread — visible in Performance Schema as elevated redo-log-flush wait time, though I have not verified the exact current wait-event name against AWS’s documentation, so treat the symptom (network-thread saturation under micro-commit load) as the citable part, not any specific event identifier.

Furthermore, Aurora’s standard billing model charges per I/O request. A workload that relies on frequent, small updates across many secondary indexes can cause Aurora storage costs to spiral, leading many engineering teams to blindly upgrade to the Aurora I/O-Optimized tier rather than fixing their application’s commit patterns. For the operational playbook on diagnosing and fixing that billing spiral once it’s already in production, see Surviving Aurora MySQL: I/O Billing Traps and Small-Instance Cliffs.

Where It Breaks

Architecture	Failure Mode	Mitigation
RDS MySQL 8.4	EBS Volume Queue Length saturation during massive bulk inserts or heavy index updates.	Pre-provision higher io2 IOPS; batch inserts; scale instance size for higher EBS bandwidth limits.
Aurora MySQL Standard	Astronomical I/O billing costs due to excessive redo log generation from poor indexing or frequent commits.	Switch to Aurora I/O-Optimized billing tier; remove unused secondary indexes; batch transactions.
RDS MySQL 8.4	Replica lag spikes during long-running write transactions due to single-threaded SQL application on replicas.	Upgrade to MySQL 8.4 multi-threaded replication; keep transactions short.
Aurora MySQL	Writer network-thread saturation from redo-log-flush wait time during high-frequency micro-commits.	Increase transaction batch sizes at the application tier to group redo log flushes.

What to Do Next

• Problem: Scaling write-heavy workloads requires navigating the physical differences between EBS-backed traditional MySQL and Aurora’s distributed storage log-shipping architecture.
• Solution: Select RDS 8.4 for predictable, storage-heavy workloads where I/O costs must be strictly controlled via provisioned EBS. Select Aurora for workloads demanding extreme crash recovery, sub-10ms replica lag, and compute offloading of I/O operations.
• Proof: AWS documentation explicitly details the elimination of data page flushing in Aurora, and CloudWatch metrics (VolumeQueueLength in RDS vs VolumeWriteIOPs in Aurora) provide the empirical evidence of these architectural differences.
• Action: Before upgrading to MySQL 8.4 LTS or migrating to Aurora, capture your peak CommitLatency and write IOPS. If I/O charges make up a meaningful share of your Aurora bill, run the numbers against AWS’s pricing calculator to see whether the I/O-Optimized tier or application-level batching wins for your specific I/O-to-compute ratio — don’t apply a fixed percentage threshold across workloads.