RDS vs Aurora vs DynamoDB: Choosing the Right AWS Database for Your Workload

Most teams choose their AWS database based on familiarity rather than fit. They pick RDS MySQL because they know MySQL. They pick DynamoDB because someone read a blog post about scale. Neither of these is a decision process.

The right database is the one that matches the access patterns of your application, the operational capacity of your team, and the compliance requirements of your business. Here is how to think through it.

Amazon RDS: Managed Relational Database

Amazon RDS gives you a fully managed relational database: MySQL, PostgreSQL, MariaDB, Oracle, or SQL Server. AWS handles provisioning, patching, backups, and Multi-AZ failover. You manage the schema, queries, and application.

When RDS is the right choice:

Your data is relational. You have entities with relationships between them, and those relationships are queried in ways that benefit from joins, foreign keys, and ACID transactions. If your application already runs on PostgreSQL or MySQL and you are migrating to AWS, RDS for PostgreSQL or RDS for MySQL is the natural fit.

Your team knows SQL well. The operational overhead of RDS is low relative to self-managed databases, but it still requires competent database administration: query analysis, index design, parameter group tuning, and capacity planning. If your team has these skills, RDS rewards them.

Your query patterns are complex and varied. Relational databases handle ad hoc queries well. If you cannot fully enumerate your access patterns in advance, or if your application has a rich reporting layer with complex aggregations, the flexibility of SQL is valuable.

RDS limitations to know:

Vertical scaling is the primary mechanism for capacity. You scale up to a larger instance class. Read replicas help with read-heavy workloads, but write throughput is bounded by a single primary instance. For most application databases this is not a constraint. For very high write-throughput systems it is.

Multi-AZ failover takes 60-120 seconds. Connections drop during failover. Applications need retry logic to handle this.

Storage and compute are not independent. You choose an instance class that determines both. If you need more storage but not more compute (or vice versa), you pay for both.

Amazon Aurora: Relational with Cloud-Native Architecture

Aurora is AWS's own cloud-native relational database, MySQL-compatible or PostgreSQL-compatible. It is not RDS for MySQL or RDS for PostgreSQL. It is a different engine that happens to speak the same protocol.

Aurora's storage layer is separate from its compute layer and distributed across three availability zones automatically. This changes several things:

Storage scales automatically up to 128 TiB without manual intervention or instance downtime. You do not provision storage upfront.

Replication is faster. Aurora replicas share the same storage as the primary, rather than replicating data. Replica lag is typically single-digit milliseconds. Failover to a replica is typically under 30 seconds.

Aurora Serverless v2 allows the database to scale compute capacity up and down in fine-grained increments (0.5 ACUs to 128 ACUs) based on actual load. For workloads with variable traffic, this can significantly reduce costs compared to a provisioned instance sized for peak.

Aurora Global Database extends the Aurora cluster across AWS regions with sub-second replication, supporting multi-region read access and fast cross-region disaster recovery.

When Aurora makes sense over RDS:

Your application is growing and you want to avoid reaching for a larger instance class every six months. Aurora's architecture handles growth more gracefully.

You need faster failover. Aurora's 30-second failover is meaningful for applications where 90-120 seconds of unavailability would breach SLAs.

You have variable workloads and want to pay only for compute you use. Aurora Serverless v2 is well-suited to dev/test environments and production services with significant traffic variation.

Aurora limitations:

It costs more than RDS for equivalent steady-state workloads. The Aurora storage model carries a cost premium over RDS storage. If your database is small, stable, and well-understood, RDS may be the better value.

Aurora only supports MySQL and PostgreSQL-compatible engines. If you need Oracle or SQL Server, Aurora is not an option.

Amazon DynamoDB: Key-Value and Document at Scale

DynamoDB is not a relational database. It is a fully managed NoSQL database built for high-throughput, low-latency key-value and document access patterns.

DynamoDB stores data in tables with items (analogous to rows) and attributes (analogous to columns). Every item has a primary key: either a partition key alone, or a partition key and a sort key. All queries in DynamoDB must include the partition key. Everything else is either a scan (expensive and to be avoided) or a secondary index.

When DynamoDB is the right choice:

Your access patterns are simple and well-defined. You retrieve an item by its primary key, or by a known partition key with a sort key range. If you can express all your query patterns as GetItem, Query, or BatchGetItem operations, DynamoDB will serve them with consistent single-digit millisecond latency at any scale.

You need automatic scaling without capacity planning. DynamoDB on-demand mode adjusts throughput automatically to match traffic. You pay per request. No provisioning, no reserved capacity decisions, no alarm at 80% CPU.

Scale is the core requirement. DynamoDB is designed for millions of requests per second. Horizontal scaling is built into the service. If your relational database is approaching write throughput limits and your access patterns are actually simple, migrating to DynamoDB is worth considering.

Your data is hierarchical or document-structured. A user profile with nested preferences, a product catalogue with variable attributes, a session store with TTL-based expiry: these fit DynamoDB's data model naturally.

DynamoDB limitations:

Queries without the partition key require a full table scan or a Global Secondary Index (GSI). GSIs add cost and require you to predict query patterns at design time. If your access patterns change, adding new GSIs is a schema migration equivalent.

ACID transactions are supported (DynamoDB Transactions) but they have constraints: up to 100 items per transaction, and they carry a 2x read/write cost. DynamoDB is not the right database for applications that need complex multi-entity transactional integrity.

DynamoDB has a 400 KB item size limit. Large documents need to be chunked or stored elsewhere (S3) with a pointer in DynamoDB.

Joins do not exist. Relational queries that touch multiple entity types need to be either pre-computed (denormalised) or run as multiple DynamoDB requests with application-level joining. If you need joins, you need a relational database.

A Decision Framework

|---|---|---|---|

| Operational overhead | Low | Low | Very low |

Work through these questions per workload:

Is the data relational? If yes, RDS or Aurora. If no, consider DynamoDB.
Are the query patterns fully known and simple? If yes, DynamoDB may fit. If no, prefer a relational database.
How much does failover time matter? Under 30 seconds pushes toward Aurora.
Is traffic highly variable? Aurora Serverless v2 or DynamoDB on-demand.
Is the workload growing fast or likely to hit vertical scaling limits? Aurora or DynamoDB.

Observability for AWS Databases

Database performance problems compound quickly. A slow query that takes 100ms instead of 10ms does not appear in your infrastructure metrics until it is causing timeouts. You need query-level visibility, not just CPU and memory.

RDS and Aurora both publish Performance Insights: a time-series view of database load broken down by wait events and SQL statements. This is the fastest path to identifying which query is causing a performance problem.

DynamoDB publishes metrics to CloudWatch including consumed read/write capacity, throttled requests, and system latency. If you see ThrottledRequests climbing, your provisioned throughput is insufficient or your partition key is hot.

With Datadog, RDS Performance Insights data, DynamoDB metrics, and application-level database query traces can be viewed together, giving you the causal chain from application behaviour to database root cause in a single screen.

Where Critical Cloud Comes In

Choosing the right database architecture and ensuring it performs reliably under production load, with the observability to diagnose problems before they affect users, is part of the managed service we provide for tech-led businesses across the UK and EMEA. See how Critical Support works.