Choosing relational vs NoSQL managed databases
data model and access pattern fit.
choose relational for complex relationships, joins, flexible queries, and strong transactions; choose NoSQL for known access patterns needing massive horizontal scale.
What's really being asked
The interviewer wants to see that you choose a database from data model, access patterns, consistency, and scale needs rather than reaching for whatever is fashionable.
The full answer
Reach for a relational service like RDS when your data is structured and highly interrelated, when you need to run joins and ad hoc or evolving queries that you cannot fully predict upfront, and when strong ACID transactions across multiple rows or tables matter, such as financial or inventory systems. Relational engines enforce a schema and referential integrity, which is valuable for data correctness, and SQL gives flexible querying. The tradeoff is that scaling writes typically means scaling up the instance, with horizontal scaling being harder. Reach for a NoSQL service like DynamoDB when your access patterns are well understood and relatively simple, often key-based lookups, when the schema is flexible or sparse, and when you need to scale horizontally to very high throughput with consistent low latency regardless of table size. The cost is that you must model the table around known access patterns, joins and ad hoc queries are awkward or impossible, and complex multi-item transactions and consistency are more limited. The decision drivers are query flexibility versus predictable patterns, transactional and consistency requirements, and the scale and latency profile you need.
The mistakes people make
Claiming NoSQL is simply newer and therefore better, ignoring relational strengths in joins and transactions. Saying relational cannot scale at all, when it scales well within limits. Picking based on familiarity or hype rather than access patterns.
What usually comes next
How does DynamoDB single-table design handle relationships? When do you need multi-row ACID transactions? How does each scale reads versus writes?
A concrete example
An order system with customers, orders, and line items that needs joins, reporting queries, and transactional consistency fits RDS, while a high-traffic session store with simple key lookups and huge scale fits DynamoDB.
Interview question
An application needs ad hoc reporting queries, joins across several entities, and multi-row transactional consistency. Which database fits best and why?
- a.A relational service, because it supports joins, flexible queries, and strong transactionsCorrect
- b.DynamoDB, because NoSQL handles arbitrary joins most efficiently
- c.Either is equivalent since both support the same query capabilities
- d.DynamoDB, because relational databases cannot enforce any consistency
Why? this is the answer
Relational databases excel at joins, ad hoc SQL, and multi-row ACID transactions. DynamoDB requires modeling around known access patterns and does not handle arbitrary joins efficiently.
Just read this? Test yourself on what you have been reading.
Read the original → aws.amazon.com
- #databases
- #rds
- #dynamodb
- #nosql
- #cloud
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on databases — each one lists the topics its interview covers.
See open roles