AWS RDS vs Aurora: When to Use Which Database

Amazon RDS and Amazon Aurora are both managed database services from AWS, but they are built differently, perform differently, and cost differently. Choosing between them is one of the most common database architecture decisions we help clients make.

This guide cuts through the marketing and gives you a practical framework for deciding which service fits your workload.

What Is the Actual Difference?

Amazon RDS is a managed wrapper around standard database engines — MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server. AWS handles provisioning, patching, backups, and failover, but the underlying database engine is the same open-source or commercial software you would run on EC2, with the same storage architecture.

Amazon Aurora is AWS’s custom-built database engine that is wire-compatible with MySQL and PostgreSQL. It uses a fundamentally different storage architecture — a distributed, fault-tolerant storage layer that replicates data six ways across three Availability Zones. The compute and storage layers are decoupled, enabling capabilities that standard RDS cannot match.

The key distinction: RDS manages standard databases for you. Aurora reimagines how the database stores and replicates data.

Performance Comparison

Throughput

AWS claims Aurora delivers up to 5x the throughput of standard MySQL and 3x the throughput of standard PostgreSQL. In practice, the performance advantage depends heavily on your workload:

• Write-heavy workloads — Aurora’s distributed storage handles writes more efficiently than RDS’s EBS-based storage, particularly at high concurrency. The performance gap is most visible here.
• Read-heavy workloads — Both perform well with read replicas. Aurora has a slight edge because replicas share the same storage layer (no replication lag for reads) and can be added in minutes.
• Mixed workloads — Aurora’s advantage is moderate. For typical OLTP workloads, expect 1.5-3x improvement over standard RDS MySQL/PostgreSQL.

Latency

Aurora’s storage layer is purpose-built for low-latency database I/O. Read latency is typically 1-2ms, and Aurora maintains consistent performance under load better than RDS, which can experience I/O contention on EBS volumes during peak periods.

Connection Management

Aurora supports up to 5,000 concurrent connections per instance (depending on instance size), compared to standard MySQL’s lower connection limits. Aurora also integrates with RDS Proxy for connection pooling, which is critical for serverless applications and Lambda-based architectures.

Availability and Durability

This is where Aurora’s architecture shines most clearly.

Aurora’s storage layer is designed to tolerate the loss of an entire Availability Zone without any data loss and with minimal failover time. Standard RDS Multi-AZ provides high availability but with longer failover times and simpler replication.

Aurora Global Database

For multi-Region disaster recovery, Aurora Global Database replicates data to up to 5 secondary Regions with less than 1 second of replication lag. Cross-Region failover promotes a secondary Region to primary in under 1 minute. RDS offers cross-Region read replicas but with higher replication lag and manual promotion.

Pricing Comparison

Aurora is not always more expensive than RDS. The pricing structures are different, and the total cost depends on your usage pattern.

Compute Costs

Instance-for-instance, Aurora compute costs are approximately 20% higher than equivalent RDS instances. However, because Aurora often performs better per instance, you may need fewer or smaller instances to handle the same workload.

Storage Costs

RDS requires you to provision storage upfront (and you pay for provisioned capacity whether you use it or not). Aurora storage auto-scales — you only pay for the storage you actually use, up to 128 TB. For databases with variable storage needs, Aurora’s auto-scaling storage can be cheaper than over-provisioning on RDS.

Aurora I/O-Optimized: For I/O-intensive workloads, Aurora offers an I/O-Optimized configuration that eliminates per-I/O charges for a 30% increase in compute price. If I/O costs exceed 25% of your total Aurora spend, this option is usually cheaper.

Aurora Serverless v2

Aurora Serverless v2 scales compute capacity automatically between a minimum and maximum ACU (Aurora Capacity Unit) based on demand. You pay per ACU-hour consumed. This is ideal for:

• Variable workloads with unpredictable traffic patterns
• Development and test databases that are idle most of the time
• Applications with periodic spikes (e.g., batch processing, seasonal traffic)

There is no RDS equivalent — RDS requires you to select a fixed instance size.

2024/2025 updates to Aurora Serverless v2:

• Scale-to-zero (re:Invent 2024): Aurora Serverless v2 can now scale all the way to zero ACUs when idle, eliminating compute costs for databases with infrequent traffic. Previously, the minimum was 0.5 ACUs. This makes development and test clusters effectively free during idle periods.
• 30% performance improvement (August 2025): AWS improved Aurora Serverless v2 scaling performance, reducing the time to scale up under sudden load spikes. The improvement is most pronounced in write-heavy workloads.
• PostgreSQL 17 support: Aurora now supports PostgreSQL 17, bringing the latest PostgreSQL features including improved vacuuming, better query planning, and new JSON functions to Aurora’s managed environment.

Aurora Limitless Database

For workloads that exceed what a single Aurora cluster can handle, Aurora Limitless Database became generally available in October 2024. Limitless supports millions of writes per second and hundreds of petabytes of data by automatically sharding data across multiple Aurora writer instances — all behind a single cluster endpoint.

Aurora Limitless uses distributed transaction processing across multiple Aurora shards. You define a shard key and Aurora handles routing, cross-shard queries, and distributed commits transparently.

Aurora DSQL: Serverless Distributed SQL

Announced at re:Invent 2024, Aurora DSQL is a serverless, distributed SQL database built for active-active multi-region deployments with zero infrastructure management. Unlike Aurora Serverless v2 (which scales compute for a single-region cluster), DSQL is designed from the ground up for distributed, globally consistent transactions:

• Active-active across multiple Regions — writes are accepted anywhere
• Zero servers to manage, no cluster to size, scales to zero automatically
• Strong consistency using a novel distributed transaction protocol
• Compatible with PostgreSQL 14+ wire protocol

Aurora DSQL is positioned for applications requiring global availability with strong consistency — think financial ledgers, inventory systems, and collaborative SaaS platforms. It is priced per read/write request and storage, with no fixed compute charges.

🔄 Update (May 2025): Aurora DSQL reached General Availability on May 27, 2025, available in 8 AWS regions. It is no longer in preview. Production workloads requiring active-active multi-region consistency can now adopt Aurora DSQL with full AWS support. Pricing starts at $0.50 per DPU-hour with 99.99% single-region and 99.999% multi-region availability SLAs.

When to Choose Aurora

High availability is critical

If your application requires sub-30-second failover, near-zero replication lag to read replicas, and the ability to survive AZ failures without data loss, Aurora’s storage architecture delivers this by default.

You need to scale reads significantly

Aurora supports up to 15 read replicas sharing the same storage layer, with near-zero replication lag. Adding a replica takes minutes and does not require data copying. RDS supports up to 5 replicas with asynchronous replication that introduces lag.

Your workload is write-heavy

Aurora’s distributed storage layer handles write-intensive workloads more efficiently than RDS’s EBS-based storage, particularly at high concurrency.

You want serverless scaling

Aurora Serverless v2 provides automatic compute scaling that RDS cannot match. For variable or unpredictable workloads, this eliminates the guesswork of instance sizing.

Multi-Region disaster recovery

Aurora Global Database provides sub-second cross-Region replication with fast failover. RDS cross-Region replicas have higher lag and require manual promotion.

When to Choose RDS

Cost sensitivity is the primary concern

For predictable workloads where standard RDS performance is sufficient, RDS is 20-30% cheaper on compute. If your database does not need Aurora’s advanced availability or performance features, standard RDS delivers a solid managed database at a lower price point.

You use Oracle or SQL Server

Aurora only supports MySQL and PostgreSQL. If your application requires Oracle or SQL Server, RDS is your managed option on AWS. (Consider evaluating whether a migration to Aurora PostgreSQL is feasible for long-term cost savings.)

Simple, low-traffic applications

For small databases serving internal tools, development environments, or low-traffic applications, Aurora’s advanced features are unnecessary overhead. A db.t3.micro RDS instance handles these workloads at minimal cost.

Predictable, steady-state I/O

If your workload has consistent I/O patterns and you can size storage appropriately, RDS’s provisioned storage (gp3) with included IOPS is simpler and more predictable than Aurora’s per-I/O pricing model. (Though Aurora I/O-Optimized addresses this for I/O-heavy workloads.)

Decision Framework

Migration Between RDS and Aurora

If you start with RDS and outgrow it, migrating to Aurora is straightforward:

1. Create an Aurora read replica from your RDS instance
2. Wait for replication to catch up
3. Promote the Aurora replica to a standalone cluster
4. Update your application connection string

The process takes hours, not days, and can be done with minimal downtime using a maintenance window for the final cutover.

Our Recommendation

For new production workloads on MySQL or PostgreSQL, we generally recommend Aurora — the availability, performance, and scaling advantages justify the price premium for most production use cases. Use Aurora Serverless v2 for variable workloads and provisioned Aurora for steady-state workloads.

For development environments, internal tools, low-traffic applications, or workloads on Oracle/SQL Server, RDS is the pragmatic choice.

Either way, the database is only as good as its configuration. Proper instance sizing, parameter tuning, connection pooling, query optimization, and backup policies are essential regardless of which service you choose. Our AWS RDS consulting covers both RDS and Aurora optimization.

Contact us to optimize your database architecture →