AWS RDS vs Aurora vs DynamoDB — Which Database to Choose (2026)

Picking the wrong AWS database is expensive — both in money and in re-architecture cost later. Here's the honest comparison.

Quick Positioning

Amazon RDS — Managed relational database. Drop-in replacement for MySQL, PostgreSQL, MariaDB, Oracle, SQL Server. Best for: existing apps that need a managed relational DB without changing anything.

Amazon Aurora — AWS's proprietary database, MySQL/PostgreSQL compatible. Significantly faster and more resilient than RDS. Best for: new relational DB workloads where you want AWS-native performance.

Amazon DynamoDB — Fully managed NoSQL (key-value + document). Best for: high-scale, low-latency, predictable access patterns. Serverless model.

Amazon RDS

What It Is

RDS manages the database engine you choose — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, or Db2. AWS handles:

• Automated backups
• Software patching
• Failover (Multi-AZ)
• Read replicas
• Storage autoscaling

You just connect your application to the endpoint.

When to Use RDS

• Lift and shift — migrating an on-prem database to AWS with minimal changes
• Familiar tooling — your team knows PostgreSQL/MySQL and wants to keep that knowledge
• Third-party software — apps that require specific DB versions (ERPs, CRMs)
• Small to medium scale — workloads that don't need extreme throughput

RDS Limitations

• Single-writer by default — Multi-AZ is for HA, not scale. Read replicas are read-only.
• Less performant than Aurora — typically 3–5x slower on equivalent hardware
• More manual management — instance sizing, parameter groups, IOPS provisioning

RDS Pricing

Pay for: instance hours + storage (GB/month) + I/O (per million requests, unless gp3) + backup storage.

Example: db.t3.medium PostgreSQL with 100GB gp3 storage: ~$70–90/month.

Multi-AZ doubles the instance cost.

Amazon Aurora

What It Is

Aurora is AWS's cloud-native relational database, compatible with MySQL 8.0 and PostgreSQL 15. Under the hood it's completely different from RDS:

• Storage is separate from compute — 6-way replication across 3 AZs, always
• Up to 15 read replicas (vs 5 for RDS) with < 10ms replica lag
• Auto-healing storage — repairs disk failures automatically
• Crash recovery in under 30 seconds (vs minutes for RDS)

Aurora Serverless v2: Scales compute capacity from 0.5 to 128 ACUs (Aurora Capacity Units) instantly, in 0.5 ACU increments. You pay per second of capacity used, not per hour of instance.

When to Use Aurora

• New relational DB workload where you're not constrained by engine compatibility
• Variable traffic — dev environments, staging, APIs with spikes → Serverless v2
• High availability required — Aurora's 6-way replication is significantly more robust than Multi-AZ RDS
• Read-heavy workloads — Global Database replicates to other AWS regions with < 1 second lag
• MySQL/PostgreSQL apps that want better performance without application changes

Aurora vs RDS Performance

AWS claims Aurora MySQL is 5x faster than MySQL on RDS, Aurora PostgreSQL is 3x faster. Real-world benchmarks show 2–4x improvement on write-heavy workloads.

The performance gap comes from the storage architecture — Aurora writes only to a shared distributed log, not to 8 separate copies (like Multi-AZ RDS does).

Aurora Pricing

Aurora is 30–50% more expensive than RDS per instance hour, but:

• You get Multi-AZ by default (no extra cost)
• Serverless v2 can save money for variable workloads (you don't pay for idle capacity)

Aurora Serverless v2 pricing: $0.12 per ACU-hour (us-east-1). Storage: $0.10/GB/month + $0.20 per million I/O requests.

For production workloads with uptime requirements, Aurora's built-in HA often makes it cheaper total than RDS Multi-AZ.

Amazon DynamoDB

What It Is

DynamoDB is a fully managed NoSQL database — serverless, with single-digit millisecond performance at any scale. Used by some of the highest-traffic applications in the world (Amazon.com's shopping cart runs on DynamoDB).

Key characteristics:

• Key-value + document model — items stored as JSON-like documents, accessed by partition key (+ optional sort key)
• Serverless — no instances to manage, scales automatically
• Consistent performance — response time stays the same whether you have 1 record or 1 billion
• Two capacity modes: On-Demand (pay per request) or Provisioned (pay per RCU/WCU)
• Global Tables: Multi-region active-active replication built-in

When to Use DynamoDB

• High scale, predictable access patterns — you know how you'll query data
• Session stores, user profiles, metadata — fixed schema, key-based lookups
• Gaming, IoT, real-time analytics — extreme write throughput
• Event sourcing — append-only workloads with DynamoDB Streams
• Serverless applications — pairs naturally with Lambda (both scale to zero)
• Global applications — Global Tables for multi-region writes

When NOT to Use DynamoDB

• Complex queries — DynamoDB has no JOINs, no aggregations, limited filtering. If you need SELECT * WHERE created_at > X AND status = Y GROUP BY user_id — use a relational DB.
• Ad-hoc analysis — reporting, analytics, dashboards → use Athena or Redshift
• Relationships between entities — foreign keys, referential integrity, complex transactions → relational DB
• You're not sure of access patterns — you must design DynamoDB schema around your queries upfront. Getting it wrong is expensive to fix.

DynamoDB Pricing

On-Demand mode: $1.25 per million write request units, $0.25 per million read request units (us-east-1). No minimum spend.

Provisioned mode: $0.00065 per WCU-hour, $0.00013 per RCU-hour. 30–50% cheaper than On-Demand for stable workloads.

Storage: $0.25/GB/month.

DynamoDB is very cheap for low to medium traffic, very expensive at extreme scale without capacity planning.

Feature Comparison Table

When to Choose Each

Choose RDS if:

• You're migrating an existing on-prem database
• Your app uses specific PostgreSQL/MySQL features
• Your team is most comfortable with relational SQL
• You want the cheapest starting option and can live with lower performance

Choose Aurora if:

• Starting a new project that needs a relational database
• You need high availability without extra complexity
• Traffic is variable — Aurora Serverless v2 saves money on dev/staging
• You want MySQL/PostgreSQL compatibility with better performance

Choose DynamoDB if:

• Your access patterns are simple and predictable
• You need consistent low latency at any scale
• Building serverless applications (Lambda + DynamoDB is a natural pair)
• Session management, caching, user preferences, real-time features
• Multi-region active-active writes are required

Common Combination Pattern

Most production AWS architectures use multiple databases:

PostgreSQL on Aurora  →  transactional data (orders, users, payments)
DynamoDB             →  sessions, feature flags, real-time state
ElastiCache (Redis)  →  hot data cache, rate limiting
S3 + Athena          →  analytics, reporting, historical data

You don't have to pick one. Use the right tool for each use case.

The Bottom Line

• New relational workload? → Aurora over RDS. The HA and performance are worth the small price premium.
• Need extreme scale with simple lookups? → DynamoDB.
• Migrating existing app? → RDS is the least friction path.
• Serverless app? → DynamoDB + Lambda + Aurora Serverless v2.

Don't over-engineer it for a new project — start with Aurora Serverless v2 (scales to zero when idle) for your relational needs, and add DynamoDB when you have a clear use case for it.