---
title: AWS RDS vs Aurora: When to Use Which Database
description: Aurora is 5× faster than MySQL, until your workload is the one where it isn't. A workload-by-workload framework for picking RDS vs Aurora, with the price-per-IOPS math and the patterns where Aurora's cost doesn't pay back.
url: https://www.joinhorizon.co/blog/aws-rds-vs-aurora-when-to-use-which-database/
datePublished: 2026-01-27T00:00:00.000Z
dateModified: 2026-10-28T00:00:00.000Z
author: palaniappan-p
category: Cloud Architecture
tags: aws-rds, aurora, database, aws, engineering-guide
---

# AWS RDS vs Aurora: When to Use Which Database

> Aurora is 5× faster than MySQL, until your workload is the one where it isn't. A workload-by-workload framework for picking RDS vs Aurora, with the price-per-IOPS math and the patterns where Aurora's cost doesn't pay back.

Aurora's "5× faster than MySQL" benchmark gets quoted in every architecture review. It's also context-dependent enough that the right answer for plenty of workloads is still standard RDS, at 20 to 30% less on compute and with a smaller blast radius when something goes wrong. The framework below walks through performance, cost, and availability decision points workload by workload, so you can pick the engine your data shape actually needs.

## Production symptoms, mechanisms, and AWS controls

| Production symptom       | Mechanism                                  | AWS control                                          |
| ------------------------ | ------------------------------------------ | ---------------------------------------------------- |
| I/O bill dominates       | Aurora charges per million I/O on Standard | Aurora I/O-Optimized for >120K IOPS/month crossover  |
| Failover takes minutes   | RDS Multi-AZ promotion time                | Aurora failover typically 30s with cluster endpoints |
| Over-provisioned for dev | Aurora minimum footprint                   | RDS db.t4g.micro for non-prod                        |

Our take: start with RDS PostgreSQL for new workloads under 1K IOPS; move to Aurora when failover SLO or read-replica fan-out justifies the baseline premium.

> **Benchmark pattern (hypothetical workload):** 5K IOPS OLTP workload, Aurora PostgreSQL I/O-Optimized saves $380/month vs Aurora Standard at 150K IOPS/month; RDS PostgreSQL Multi-AZ sufficient at 800 IOPS with $210/month lower baseline than Aurora cluster.

## How RDS and Aurora differ

**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 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.

RDS manages standard database engines for you. Aurora changes 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 matters for serverless applications and Lambda-based architectures.

## Availability and Durability

| Feature              | RDS (Multi-AZ)              | Aurora                                       |
| -------------------- | --------------------------- | -------------------------------------------- |
| Data replication     | Synchronous to 1 standby    | 6 copies across 3 AZs                        |
| Failover time        | 60-120 seconds              | Typically under 30 seconds                   |
| Read replicas        | Up to 5 (async replication) | Up to 15 (shared storage, near-zero lag)     |
| Storage durability   | 99.999% (EBS)               | 99.999999999% (11 nines)                     |
| Self-healing storage | No                          | Yes (automatic repair of data blocks)        |
| Survive AZ failure   | Yes (with Multi-AZ)         | Yes (can lose 2 copies and still read/write) |

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

| Component | RDS                               | Aurora                         |
| --------- | --------------------------------- | ------------------------------ |
| Storage   | $0.115/GB/month (gp3)             | $0.10/GB/month                 |
| I/O       | Included in gp3 baseline          | $0.20 per million I/O requests |
| Backups   | Free up to 1x provisioned storage | Free up to 1x cluster volume   |

RDS requires you to provision storage upfront (and you pay for provisioned capacity whether you use it or not). Aurora storage auto-scales, so 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, which adds improved vacuuming, better query planning, and new JSON functions.

## 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.

| Capability           | Standard Aurora               | Aurora Limitless              |
| -------------------- | ----------------------------- | ----------------------------- |
| Max write throughput | ~200K transactions/second     | Millions of transactions/sec  |
| Max storage          | 128 TB                        | Hundreds of petabytes         |
| Sharding             | Manual or application-managed | Automatic, transparent        |
| Application changes  | None                          | Minimal (choose shard key)    |
| Use case             | Most production workloads     | Hyperscale, multi-tenant SaaS |

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, such as 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

| Question              | Choose Aurora If...                      | Choose RDS If...                  |
| --------------------- | ---------------------------------------- | --------------------------------- |
| Downtime tolerance?   | Minutes matter; need sub-30s failover   | 1-2 minute failover is acceptable |
| Read scale?           | Need 5+ read replicas with low lag       | 1-3 replicas are sufficient       |
| Write throughput?     | High-concurrency writes are a bottleneck | Write volume is moderate          |
| Workload variability? | Traffic is unpredictable (Serverless v2) | Traffic is predictable            |
| Database engine?      | MySQL or PostgreSQL                      | Oracle, SQL Server, MariaDB       |
| Budget priority?      | Willing to pay 20% more for features     | Cost is the primary constraint    |
| Multi-Region DR?      | Required with RPO < 1 second             | Not required or RPO > minutes     |
| Hyperscale needed?    | Millions of writes/sec (Limitless)       | Standard throughput is sufficient |
| Global active-active? | Required with strong consistency (DSQL)  | Single-region or eventual OK      |

## Migration Between RDS and Aurora

If you start with RDS and outgrow it, the **classic promotion path** stays valid for many MySQL-compatible and PostgreSQL workloads:

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

That flow takes hours, not days, and usually lands in **one reader topology** mirrored from the source, which is adequate for straightforward cutovers.

**PostgreSQL caveat:** workloads that rely on **logical replication** after a snapshot-based seed, or that need **multi-reader parity testing**, **combined major-version bumps**, or **subset replication**, run into WAL / **LSN** continuity quirks between RDS and Aurora. Rather than repeating AWS’s procedural steps here, use our comparison section **[Moving from RDS PostgreSQL to Aurora PostgreSQL](https://www.joinhorizon.co/compare/aws-rds-vs-aurora/#moving-from-rds-postgresql-to-aurora-postgresql)** plus [AWS’s seeded logical replication runbook](https://aws.amazon.com/blogs/database/migrating-amazon-rds-for-postgresql-to-amazon-aurora-using-seeded-logical-replication/).

## 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.

Instance sizing, parameter tuning, connection pooling, query optimization, and backup policies matter on either service. Our [AWS RDS consulting](https://www.joinhorizon.co/services/aws-rds-consulting/) covers both RDS and Aurora optimization.

[Contact us to optimize your database architecture →](https://www.joinhorizon.co/contact-us/)

## More in This Track

Part of the **Engineering Guides** library (June 2026).

- Previous: [Part 4](https://www.joinhorizon.co/blog/postgresql-vacuum-index-bloat-sharding-hot-partitions-aws/)
- Browse tracks: [Engineering Guides hub](https://www.joinhorizon.co/resources/engineering-guides/)

## Related reading

- [Managed Database Operations on AWS (2026): RDS/Aurora Buyer Guide](https://www.joinhorizon.co/blog/aws-managed-database-ops-rds-aurora-buyer-guide-2026/)
- [AWS Cloud Center of Excellence (CCoE): Operating Model, RFCs, and How WAR + FinOps Connect](https://www.joinhorizon.co/blog/aws-cloud-center-of-excellence-operating-model-2026/)
- [AWS for Retail: The Complete Guide for eCommerce Teams](https://www.joinhorizon.co/blog/aws-for-retail-complete-guide/)
- [AWS Global Accelerator vs CloudFront & Route 53 (2026)](https://www.joinhorizon.co/blog/aws-global-accelerator-when-to-use-multiregion/)
- [AWS IoT Greengrass v2: Edge Computing for Factory Floors](https://www.joinhorizon.co/blog/aws-iot-greengrass-v2-edge-computing-factory-floor/)
- [AWS IoT SiteWise Native Anomaly Detection for Predictive Maintenance](https://www.joinhorizon.co/blog/aws-iot-sitewise-native-anomaly-detection-predictive-maintenance/)
- [AWS IoT Solutions: Architecture Patterns for Connected Devices](https://www.joinhorizon.co/blog/aws-iot-solutions-architecture-guide/)
- [AWS IoT TwinMaker: Digital Twin Architecture for Manufacturing](https://www.joinhorizon.co/blog/aws-iot-twinmaker-digital-twin-manufacturing/)
- [AWS Managed Services vs AWS Support Plans: What](https://www.joinhorizon.co/blog/aws-managed-services-vs-aws-support-plans-difference/)
- [AWS Architecture for Black Friday: How Retail Teams Prepare for Peak Traffic](https://www.joinhorizon.co/blog/aws-retail-architecture-black-friday-peak-traffic/)
- [12 Benefits of Hiring a Certified AWS Consultant — With Real ROI](https://www.joinhorizon.co/blog/benefits-of-hiring-certified-aws-consultant/)
- [Custom AWS Development for Retail: When Off-the-Shelf Is Not Enough](https://www.joinhorizon.co/blog/custom-aws-development-retail-ecommerce/)
- [How to Optimize EC2 for High-Performance APIs](https://www.joinhorizon.co/blog/ec2-high-performance-api-optimization/)
- [Microservices Design Patterns on AWS: 10 Patterns That Actually Matter in 2026](https://www.joinhorizon.co/blog/microservices-design-patterns-aws-production-guide-2026/)
- [How to Choose Between Nginx, FrankenPHP, and Modern Web Runtimes (2026)](https://www.joinhorizon.co/blog/nginx-frankenphp-modern-runtimes-comparison/)
- [OPC-UA on AWS: SiteWise Edge Gateway Setup and Best Practices](https://www.joinhorizon.co/blog/opc-ua-aws-iot-sitewise-edge-gateway-setup/)
- [OT/IT Convergence on AWS: Architecture Patterns for Smart Manufacturing](https://www.joinhorizon.co/blog/ot-it-convergence-aws-architecture-patterns/)
- [How to Build Reliable Queue Systems on AWS (SQS, Kafka, Redis)](https://www.joinhorizon.co/blog/reliable-queue-systems-aws-sqs-kafka-redis/)
- [How to Tune PHP, Node.js, Python, and Go for High Concurrency on AWS](https://www.joinhorizon.co/blog/tune-php-node-python-go-high-concurrency/)

## FAQ

### When should I keep RDS instead of Aurora?
Keep RDS when cost is the primary constraint, I/O is steady on gp3, traffic is low, or you need Oracle or SQL Server. Aurora is MySQL and PostgreSQL only. Standard RDS is often 20 to 30% cheaper on compute when you do not need sub-30s failover or 15 low-lag replicas.

### Is Aurora always 5× faster than MySQL?
No. That benchmark is workload-dependent. Write-heavy high-concurrency and read-scale with many replicas are where Aurora’s storage architecture pays. Plenty of internal tools belong on a small RDS instance at a smaller blast radius.

### When does Aurora Serverless v2 beat instance-sized RDS?
When traffic is unpredictable and you would otherwise guess instance size. Predictable steady I/O can still prefer RDS provisioned storage. Aurora I/O-Optimized exists for I/O-heavy Aurora bills. It does not make every RDS workload an Aurora candidate.

### Do I need Aurora DSQL or Limitless to start?
No. Those are specific scale-out paths (DSQL GA May 27, 2025; Limitless for shard-style growth). Start from the RDS vs Aurora decision table in this post, then the which-AWS-database tree if you are unsure.

---

*Source: https://www.joinhorizon.co/blog/aws-rds-vs-aurora-when-to-use-which-database/*