Amazon RDS vs DynamoDB: Choosing Between Relational and NoSQL on AWS

Definition

Amazon RDS (Relational Database Service) is a managed service for traditional relational database engines — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Db2 — that speak SQL and enforce a fixed schema with typed columns, primary keys, foreign keys, and ACID transactions.

Amazon DynamoDB is a fully managed, serverless NoSQL key-value and document database. It stores flexible-schema items up to 400 KB each, indexed by a primary key (partition key, optionally plus sort key), and delivers single-digit millisecond latency at any scale.

These two services represent the two dominant data-modeling paradigms on AWS, and the choice between them is one of the most common architectural decisions exam candidates face.

How It Works

RDS runs on managed EC2 instances with attached EBS storage. You pick an engine, an instance class, and a storage type; AWS handles the OS, database software, patching, backups, and (optionally) Multi-AZ failover. Applications connect over TCP using the engine's native protocol and SQL dialect.

DynamoDB has no servers to provision. You create a table, declare a partition key (and optional sort key), and start calling the HTTP API through the AWS SDK. Data is sharded by a hash of the partition key across many partitions behind the scenes, replicated three-ways across AZs, and accessed directly by partition routing — not by scanning.

The operational model is fundamentally different:

• RDS: instance-based, long-lived TCP connections, SQL, joins, transactions across many rows.
• DynamoDB: request-based, stateless HTTPS calls, primary-key lookups, transactions up to 100 items, item-level operations.

Key Features and Limits

Data model

| | RDS | DynamoDB | | --- | --- | --- | | Model | Relational tables with rows/columns | Key-value / document items | | Schema | Enforced, typed, altered via DDL | Flexible — only the primary key is required | | Query language | SQL (SELECT, JOIN, GROUP BY) | PutItem/GetItem/Query/Scan; PartiQL optional | | Joins | First-class | None — denormalize or application-side join | | Transactions | Multi-row ACID, savepoints | ACID up to 100 items across tables | | Item / row size | Engine-dependent, typically MBs | 400 KB hard limit |

Scale and performance

| | RDS | DynamoDB | | --- | --- | --- | | Vertical scale | Bigger instance class | Automatic partition splitting | | Horizontal scale | Read Replicas (up to 5, Aurora 15) | Unlimited shards under the hood | | Latency | Low ms typical | Single-digit ms, µs with DAX | | Multi-Region | Cross-Region Read Replica / Aurora Global DB | Global Tables (multi-active) | | Throughput ceiling | Instance-bound | Effectively unbounded (On-Demand) |

Availability and durability

• RDS: Multi-AZ synchronous standby; Read Replicas for scaling; 99.95% SLA (Multi-AZ).
• DynamoDB: Three-AZ replication by default; 99.99% SLA; 99.999% SLA with Global Tables.

Common Use Cases

Pick RDS when…

1. You need SQL joins, aggregations, or ad-hoc queries across many tables.
2. Your schema is well understood and stable — a normalized model fits the domain.
3. You are migrating an existing relational app (Oracle, SQL Server, MySQL) to AWS with minimal code change.
4. Reporting tools (Tableau, Power BI, Metabase) need a standard SQL endpoint.
5. Strong multi-row transactions and foreign-key integrity matter.

Pick DynamoDB when…

1. Access patterns are key-based and known upfront (e.g., user-by-ID, order-by-customer).
2. Traffic is spiky or unpredictable and you want scale-to-zero economics via On-Demand.
3. You need single-digit-millisecond latency at massive scale without capacity planning.
4. The app is serverless (Lambda, Step Functions) and connection pooling to a relational DB is painful.
5. You want multi-Region active-active via Global Tables.
6. Use cases: session stores, shopping carts, gaming leaderboards, IoT telemetry, event logs, user preferences.

Pricing Model

RDS bills per instance-hour (doubled for Multi-AZ), per GB-month of storage, plus provisioned IOPS/throughput, backup overages, and data transfer. Cost is mostly fixed — idle instances still bill.

DynamoDB bills per request (On-Demand) or per provisioned capacity unit-hour (RCU/WCU), plus per-GB-month of storage and optional features (Streams, Global Tables, DAX, PITR, backups). Cost tracks usage — idle tables cost only the storage footprint.

Rule of thumb: for steady, predictable workloads, a right-sized Reserved RDS instance can be cheaper than the equivalent DynamoDB workload; for spiky or low-utilization workloads, DynamoDB On-Demand often wins on both price and operational simplicity.

Pros and Cons

RDS

Pros: mature SQL ecosystem, joins and ad-hoc queries, engine choice (including commercial DBs), familiar tools.

Cons: per-instance pricing, vertical-scale ceiling, connection pooling required for Lambda, slower multi-Region story (except Aurora Global DB).

DynamoDB

Pros: truly serverless, horizontal scale without limits, single-digit ms latency at any scale, Global Tables, tight Lambda/EventBridge integration.

Cons: no joins or ad-hoc SQL, 400 KB item cap, access patterns must be modeled upfront, GSIs cost extra, scans are expensive.

Comparison with Alternatives

| | RDS | DynamoDB | Aurora | DocumentDB | | --- | --- | --- | --- | --- | | Model | Relational | NoSQL key-value/document | Relational (MySQL/Postgres-compatible) | Document (MongoDB-compatible) | | Scaling | Vertical + Read Replicas | Horizontal, serverless | Up to 15 replicas, 128 TiB shared storage | Up to 15 replicas, shared storage | | Best for | Standard relational workloads | Key-value at scale, serverless | Heavy MySQL/Postgres needing HA | MongoDB-style document workloads | | Pricing | Per instance-hour | Per request / capacity unit | Per instance-hour or ACU | Per instance-hour |

Exam Relevance

• Solutions Architect Associate (SAA-C03) — the single most frequently tested decision. Watch for keywords: "relational", "joins", "ACID across tables", "reporting" → RDS. "Key-value", "serverless", "single-digit ms at any scale", "unpredictable traffic", "session store", "shopping cart" → DynamoDB.
• Developer Associate (DVA-C02) — Lambda with RDS Proxy (relational) vs native SDK calls (DynamoDB), connection pooling implications.
• Database Specialty (DBS-C01) — deep coverage: migration paths, cost modeling, multi-Region DR, access-pattern modeling for DynamoDB, Aurora vs RDS vs DynamoDB positioning.

Classic exam trap: a question mentions "flexible schema" or "millions of users with unpredictable traffic" and "single-digit millisecond latency" — the answer is almost always DynamoDB. A question mentioning "complex joins", "existing ORM", or "BI tool via JDBC" — the answer is RDS or Aurora.

Frequently Asked Questions

Q: Can DynamoDB replace RDS entirely?

A: Rarely. DynamoDB excels at key-based access patterns that you model upfront, but it does not support ad-hoc SQL, joins, group-by aggregations, or foreign-key integrity. If your application fundamentally reports across entities (e.g., "sales by region by product by month"), a relational database is the better fit. Many real-world architectures use both: RDS/Aurora for transactional and reporting workloads, DynamoDB for high-scale key-value paths like sessions, carts, and activity feeds.

Q: Which is cheaper, RDS or DynamoDB?

A: It depends on utilization. For a steady, high-utilization workload, a reserved RDS instance can beat DynamoDB on total cost of ownership. For a spiky or low-utilization workload — especially serverless apps with scale-to-zero periods — DynamoDB On-Demand almost always wins because you only pay per request and there is no idle instance bill. Always model your peak and average throughput, storage, and data-transfer costs before choosing on price alone.

Q: How do transactions compare between RDS and DynamoDB?

A: RDS offers classic relational transactions — begin/commit/rollback across any number of rows and tables in the same database, with savepoints and varying isolation levels. DynamoDB offers TransactWriteItems and TransactGetItems operations that provide ACID semantics across up to 100 items in the same or different tables within a single Region. For most transactional needs DynamoDB transactions are sufficient, but workloads with long, complex multi-row transactions (e.g., accounting ledgers with hundreds of rows per transaction) remain easier to model relationally.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS documentation before making production decisions.