IntermediateIn-depth4 min readUpdated 2 Oct 2026

What is the difference between RDS and DynamoDB, and when would you use each?

SHORT ANSWER

RDS is a managed relational database service running engines like MySQL or PostgreSQL, with SQL, joins and transactions. DynamoDB is a serverless key-value and document database that gives fast, predictable performance at very large scale if you design around known access patterns. Use RDS for relational data and flexible queries; use DynamoDB for simple, high-volume lookups by key.

Explain it simply

RDS is like a well-organised college office with registers for students, courses and fees, all linked by roll number. You can ask any question: "students from Patna who paid fees late and scored above 80". The clerk can answer, though complex questions take time, and there is only so much one office can handle.

DynamoDB is like a row of numbered lockers. Give the locker number and you get the contents instantly, whether there are a thousand lockers or a billion. But if you ask "which lockers contain a blue bag?", it has to open every locker. You must know how you will look things up before you build it.

Example

text

RDS (PostgreSQL) for a college ERP:
  students(id, name, city)
  enrollments(student_id, course_id, grade)
  courses(id, title)
  -> SELECT s.name FROM students s JOIN enrollments e ... WHERE e.grade > 80;

DynamoDB for a ticket-booking session store:
  Table: Sessions
  Partition key: session_id
  -> GetItem(session_id = "abc123")   // fast, any scale
  Table: Orders
  Partition key: user_id, Sort key: order_time
  -> Query(user_id = "u42", order_time > "2026-09-01")

How it works

RDS (Relational Database Service)

Engines include MySQL, PostgreSQL, MariaDB, Oracle, SQL Server and Db2. Amazon Aurora is a related AWS engine compatible with MySQL and PostgreSQL.
AWS handles provisioning, patching, automated backups and point-in-time restore. You still choose instance size and storage.
Multi-AZ keeps a standby in another Availability Zone for automatic failover. Read replicas spread read traffic.
Scaling writes mostly means a bigger instance (vertical scaling), and SQL with joins and ACID transactions gives you query flexibility.

DynamoDB

Fully managed and serverless: no instances to size or patch. Data is replicated across multiple AZs in the Region.
Every item is found by its primary key: a partition key, or a partition key plus sort key. Lookups by key are typically single-digit milliseconds at any scale.
Capacity is either on-demand (pay per request, scales automatically) or provisioned (set read/write capacity, optionally with auto scaling).
Queries must use the key. For other access patterns you add secondary indexes (GSIs or LSIs). There are no joins. It does support transactions across items, but with limits.

Real-world use

RDS: banking ledgers, college ERPs, e-commerce orders and inventory, admin dashboards with reports, anything where data is relational and queries change over time.
DynamoDB: user sessions, shopping carts, leaderboards, IoT readings, high-traffic event data during something like a Big Billion Days sale where traffic jumps suddenly and the access pattern is simple.

Many systems use both: RDS for the source-of-truth relational data and DynamoDB for a hot, high-volume path.

Common mistakes

Picking DynamoDB because "NoSQL scales", then needing joins and ad hoc reports.
Designing a DynamoDB table like SQL tables, one per entity, without listing the queries first.
Choosing a partition key with few values (like status), creating hot partitions.
Using Scan for everyday queries. It reads the whole table.
Running RDS in a single AZ in production with no Multi-AZ or backups tested.

What to say in the interview

"RDS is managed relational databases: MySQL, PostgreSQL and others, with SQL, joins and ACID transactions. AWS handles backups, patching and Multi-AZ failover, but it scales mainly vertically plus read replicas. DynamoDB is a serverless key-value and document store with consistently fast lookups at almost any scale, but I must design keys and indexes around known access patterns, and there are no joins. I'd choose RDS when data is relational or queries are unpredictable, and DynamoDB for simple, high-volume access by key, like sessions, carts or event data."

Follow-up questions

How do you choose a good partition key in DynamoDB?
What is the difference between Multi-AZ and a read replica in RDS?
What is eventual versus strongly consistent read in DynamoDB?
When would you pick Aurora over standard RDS?

Go deeper

Read these once the basics above feel easy.

DynamoDB reads are eventually consistent by default; you can request strongly consistent reads on the base table and local secondary indexes, but not on global secondary indexes. DynamoDB Streams capture item changes, which can trigger Lambda for things like updating a search index. In RDS, Multi-AZ is for availability (the standby does not serve reads in the classic setup), while read replicas are for read scaling.

#aws #rds #dynamodb #databases #sql #nosql