The Interview Question You Will Get Asked
"Should we use or NoSQL for this system?"
This question comes up in every system design interview. Every single one. The interviewer is not looking for a one-word answer, they are testing whether you understand the trade-offs deeply enough to make a reasoned decision from the specific requirements in front of you.
Here is the uncomfortable part: most of the popular takes on this are wrong, and they are wrong in a way that is easy to check.
" is faster." Faster at what? Later in this lesson you will see the same data, on the same server, where the document shape is about twice as fast for one query and about three times slower for another.
"SQL does not scale." Instagram runs on PostgreSQL at a scale most companies will never approach.
"NoSQL is for unstructured data." Cassandra makes you declare a schema. DynamoDB makes you declare your keys before you write a single item.
The framing itself is also about fifteen years old. It comes from a period when relational databases genuinely could not scale horizontally, and that turned out to be an engineering limit rather than a law of nature. There is now a whole third category that gives you SQL, joins and transactions on a cluster, and most people arguing about this have never heard of it.
This lesson goes deep. Six database models, what each one physically does, the trade-offs measured rather than asserted, and how to reason about the decision in a real project and in an interview.
The One Decision Underneath All of This
Before the models and the acronyms, there is a single decision that everything else follows from, and it has nothing to do with which product you buy.
Where does related data live? Beside the entity it belongs to, or inside it?
Read the left panel and the right panel as answers to the same question, because they are. The data is identical. Only its shape differs.
On the left, orders are a table of their own and each row points back at a user by id. Any question about orders in general is easy, and getting one user with their orders takes a join.
On the right, the orders are a value inside Alice. Getting Alice and her orders takes one read, and there is no way to ask about all orders without opening every user.
That is the whole subject. Everything below is a consequence: joins, schemas, transactions, , and every trade-off in the comparison table at the end.
It is worth saying clearly that this is not a product decision. You can embed JSON in PostgreSQL. You can store normalised references in MongoDB. Choosing a database and choosing a data shape are two separate decisions that people routinely make as one.