AWS Database Comparison: RDS vs Aurora vs DynamoDB

AWS database choice usually comes down to: do you need relational with joins and transactions, or do you have well-defined access patterns at huge scale that justify the trade-offs of NoSQL.

RDS — the standard managed relational

• Managed Postgres, MySQL, MariaDB, Oracle, or SQL Server; AWS handles backups, patching, multi-AZ failover
• Same database engine you'd run yourself, just managed; maximum portability across clouds and on-prem
• Best for standard relational workloads up to 64TB and moderate traffic; the default for most Spring apps
• Failover takes 60 to 120 seconds in multi-AZ — fine for 99.9% SLOs but not for tighter

Aurora — AWS's reimplementation of MySQL and Postgres

• Compute is MySQL or Postgres compatible — existing apps work unchanged
• Storage is the magic: 6-way replicated across 3 AZs, decoupled from compute
• 5x throughput of RDS MySQL, ~30 second failover, up to 15 read replicas, supports up to 128TB
• Aurora Serverless v2 scales compute by ACU in seconds — cheaper than provisioned for variable traffic
• Trade-off: AWS-specific (some lock-in), slightly more expensive at low scale

DynamoDB — fully managed NoSQL

• Single-digit millisecond latency at any scale; tested at trillions of requests per day at Amazon retail
• On-demand pricing scales perfectly with unpredictable traffic; provisioned mode for steady predictable workloads
• The catch: you must design around access patterns at the start — single-table design is the canonical pattern
• Lacks joins; limited query flexibility; ad-hoc queries are expensive or require GSIs (global secondary indexes)

The decision tree

• Standard web app, predictable scale: RDS Postgres — the default
• High-traffic relational, faster failover, more read replicas: Aurora
• Key-value or document workload at huge scale with well-defined queries: DynamoDB
• Specialized: DocumentDB for MongoDB API, Neptune for graphs, Keyspaces for Cassandra, Timestream for time-series, OpenSearch for search

The classic anti-pattern

• Picking DynamoDB because "it scales" without designing access patterns first
• Single-table design requires upfront thinking about every query you'll need; adding a new query pattern later requires a GSI or table redesign
• RDBMS is much more forgiving to evolving requirements

Hidden trade-offs to call out

• RDS multi-AZ failover is slower than people expect (60 to 120 seconds); Aurora's 30 seconds is materially better for tight SLOs
• Aurora I/O-Optimized vs Standard — I/O-heavy workloads get expensive on Standard; crossover around 25 percent I/O-spend ratio; switch via console
• DynamoDB hot partitions — 1000 WCU / 3000 RCU max per partition; design partition keys with high cardinality (user_id, not country)
• Aurora's 6-way replicated storage is more durable than RDS multi-AZ's 2 copies
• RDS Proxy is critical for Lambda + RDS to avoid connection storms; multiplexes connections

Default recommendation

• Start new projects on RDS Postgres for relational — portable, familiar, cheap
• Migrate to Aurora when scale or failover SLO demands it
• Reserve DynamoDB for specific high-scale use cases where access patterns are clear and won't change much
• For specialized needs (graph, time-series, search), use the purpose-built services rather than forcing them into a relational or DynamoDB model