'S3 is not a database' answers what S3 isn't. This lesson answers what actually is one — and why AWS offers two very different kinds, not one.
13 min read
Check your understanding
Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.
Question 1 of 3
A DynamoDB table stores order data, and a related "customer" field is duplicated directly inside each order item instead of being looked up from a separate customers table. Why is this considered correct DynamoDB design, not a mistake?
Stuck? Ask the AI tutor
Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.
Interview questions on Storage & Databases: S3, DynamoDB, RDS
What interviewers actually ask about this, and what a strong answer has to cover.
A new feature needs to store user activity events at high volume. Would you reach for S3, DynamoDB, or RDS, and how would you decide?
A strong answer covers
Rule out S3 correctly — it's object storage with no query model, not a fit for structured, queryable event data
Decide between DynamoDB and RDS based on access patterns known upfront (favors DynamoDB) versus need for joins/arbitrary queries/flexibility (favors RDS), not a general SQL-vs-NoSQL preference
Understand DynamoDB's tradeoff: scales cheaply and predictably for known access patterns, but has no JOIN equivalent
Likely follow-ups
If this data later needs to be joined with customer records for a reporting feature, does your answer change?
Why might a team deliberately duplicate data across a DynamoDB item instead of normalizing it the way they would in a relational database?
Three storage services cover almost everything a frontend-adjacent developer runs into, each solving a genuinely different problem:
S3 — object storage. Files, addressed by key, with no query language over their contents. Right for anything you fetch whole: built assets, images, uploads, backups.
DynamoDB — a managed NoSQL database. Data is stored as items (roughly: JSON documents) in tables, looked up primarily by a key you define upfront. Scales to enormous, unpredictable traffic with consistent low-latency lookups, in exchange for a much more restrictive query model than SQL.
RDS — managed relational (SQL) databases (Postgres, MySQL, and others) — the familiar tables/joins/arbitrary-query model, with AWS handling backups, patching, and failover instead of a team running Postgres on a server themselves.
See it in a real thing: one app, all three at once
Three storage models, three different jobsStep 1 of 3
S3: whole files, no query language — right for content fetched as-is, like a build's static assets.
A typical full-stack app on AWS uses all three simultaneously, for different data:
S3 holds the built frontend bundle and user-uploaded images — content served whole, not queried.
DynamoDB holds something high-volume and simple to key by, like session state or a user's activity feed — lookups are always "give me this exact key," never "find everything where X > Y."
RDS holds the actual relational business data — orders linked to customers linked to products — anything that genuinely needs joins, transactions, or ad-hoc queries a NoSQL key-value lookup can't express.
What people usually miss
Watch out
DynamoDB has no real equivalent to a SQL JOIN. Data that would be two related tables in Postgres often gets deliberately duplicated (denormalized) across a DynamoDB item specifically to avoid needing a second lookup — this looks wrong to someone thinking in relational terms, but it's the correct, idiomatic pattern for the access-pattern-first model DynamoDB is built around.
S3 objects are immutable in a specific sense: there's no partial update. Changing one byte of a file means uploading the whole object again — there's no equivalent to a database's UPDATE statement touching one field.
RDS still requires you to manage scaling decisions DynamoDB handles automatically. Read replicas, connection pooling, and vertical scaling (a bigger instance) are still your call with RDS — "managed" means AWS handles the operational toil (patching, backups, failover), not that scaling becomes automatic the way it is with DynamoDB's on-demand capacity mode.
S3 storage classes are a real cost lever, not just a checkbox. Infrequently-accessed data (old logs, backups) in S3 Standard costs meaningfully more than the same data in S3 Glacier — the tradeoff is retrieval time and complexity, not just a settings toggle with no consequence.
Why this matters in interviews
"Would you use DynamoDB or RDS for this?" is a real, common systems question, and the strong answer starts with the access pattern — how will this data actually be looked up, does it need arbitrary queries or joins — rather than a general opinion about SQL versus NoSQL. That distinction (access-pattern-first vs. query-flexibility-first) is the actual decision, not a technology preference.