The database decision comes up early in every project and gets relitigated constantly as the system grows. RDS, Aurora, and DynamoDB cover very different use cases, but the marketing around all three is designed to make each sound like the right choice for everything. As someone who has migrated data between all three and debugged the aftermath of wrong initial choices, I learned what actually separates them. Today I’ll share the honest version.
This article includes affiliate links. We may earn a commission at no extra cost to you.
RDS: The Baseline
RDS is managed PostgreSQL, MySQL, MariaDB, Oracle, or SQL Server. If you know you need a relational database and you don’t have a specific reason to use Aurora, RDS is the default. It handles backups, patching, and Multi-AZ failover. The operational overhead is low compared to running your own database on EC2.
Where RDS makes sense: applications that need a well-understood relational model, teams that know SQL, projects where the workload is predictable and not particularly high-scale. RDS Multi-AZ gives you automatic failover with roughly 1–2 minute downtime. Read replicas are available if you need to scale reads.
Where RDS struggles: very high throughput write workloads, connections from many concurrent Lambda functions (connection exhaustion is a real problem — use RDS Proxy if you’re running serverless), and situations where you need to scale storage instantly without downtime.
Aurora: RDS with a Better Engine
Aurora is AWS’s custom MySQL- and PostgreSQL-compatible database. The underlying storage layer is different from standard RDS — it’s distributed across six copies across three availability zones, which makes it more resilient and faster at writes. Failover is typically under 30 seconds versus 1–2 minutes for standard RDS Multi-AZ.
Aurora storage scales automatically up to 128TB. You don’t provision storage — it expands as you need it. This alone justifies Aurora for many production databases where predicting storage growth is uncertain. That’s what makes Aurora endearing to teams running production databases — the storage just grows, and you deal with it at billing time instead of at 2 AM when a disk fills up.
Cost comparison: Aurora is roughly 20% more expensive than RDS for equivalent compute, but the storage model and Multi-AZ architecture are different enough that direct comparison is approximate. For most teams running production PostgreSQL at scale, Aurora’s operational advantages are worth the cost difference. For development environments and low-traffic applications, standard RDS is cheaper.
DynamoDB: A Completely Different Thing
DynamoDB is not a relational database. It’s a key-value and document store. The access patterns you define when you design your table schema are the access patterns you get — you can’t query arbitrary columns the way you can with SQL.
What DynamoDB is actually good for: applications with extremely high throughput (millions of requests per second), workloads where a single primary key lookup or range scan is the dominant access pattern, applications that need single-digit millisecond latency at any scale, and event-driven architectures where DynamoDB Streams triggers Lambda functions.
Where DynamoDB fails: complex relational queries, ad-hoc reporting, many-to-many relationships without careful schema design, and teams without experience modeling data for key-value stores. Getting the partition key and sort key design wrong leads to hot partitions and poor performance that’s expensive to fix after the fact. I’m apparently someone who has done this migration twice — once by choice, once because the first migration was wrong.
The Decision Framework
Start with two questions. First: do you need to query this data in ways you can’t fully predict today? If yes, use a relational database — RDS or Aurora. Second: is your primary access pattern a key lookup or range scan on a known key, at high volume or with very low latency requirements? If yes, DynamoDB is worth evaluating.
Between RDS and Aurora: use Aurora for production systems where failover speed and automatic storage scaling matter. Use RDS for development environments, low-traffic applications, or when you’re running a database engine Aurora doesn’t support.
The decision you’ll regret: choosing DynamoDB because it scales and then discovering three months in that you need to run a report across multiple attributes. Migrations from DynamoDB to relational databases are painful. Make sure your access patterns are actually key-value before committing.
Leave a Reply