SQL vs NoSQL

Seven modules of tables, keys and normalization. Then someone in the room says:

"Why bother? We just use MongoDB. No schema, no joins, way faster."

Is he right?

Why & what

Partly — and the honest answer is more interesting than either side of the usual argument.

Relational databases make you decide the shape of your data before you store any, and in return they enforce it forever. That's a genuine cost when the shape is still changing, or when one machine can't hold your data.

NoSQL is a family of databases that drop some relational guarantees — fixed schema, joins, sometimes strict consistency — in exchange for flexibility and easier scaling across many machines.

Note the word drop. Everything NoSQL gains, it gains by giving something up.

How it works

Store Aisha's record both ways.

1. Relational. Student(roll_no, name, email) and Enrollment(roll_no, course, grade). The columns are fixed. Adding a phone number means altering the table. Getting her grades means a join.
2. Document (NoSQL). One JSON document holding Aisha and her enrollments nested inside it. Reading everything about her is one lookup, no join. Adding a phone number means... just adding it, to her document only.
3. Now the catch. Ben's document might not have a phone number. Or might spell the field differently. Nothing stops it — the database enforces nothing. Every guarantee from Module 3 is now your application's job.
4. The scaling difference. Relational databases traditionally scale up — buy a bigger machine. NoSQL systems are built to scale out — add more machines. Joins and cross-machine transactions are exactly what makes scaling out hard, so dropping them is what makes it easy.
5. The honest answer. Use relational unless your data is genuinely shapeless, or you genuinely need many machines. Most student projects and most company applications are neither.

Notice: NoSQL trades guarantees for flexibility — that trade is the whole answer.

Common confusion

"NoSQL is faster" is not a real claim. Faster at what? A document store is faster at fetching one whole nested record. A relational database is faster at "average grade per course across 2 million enrollments." They're fast at different shapes of question.

Second: "NoSQL" doesn't mean "no SQL." It's usually read as "not only SQL," and several NoSQL systems now offer SQL-like query languages. The name is historical, not descriptive.

Third: schema-less doesn't mean no schema. The schema still exists — it just moved into your application code, where nothing enforces it. Many teams discover this the hard way, three years in.

Interview angle

1. "When would you choose NoSQL over a relational database?" — Genuinely variable record shapes, very high write volume, or data too large for one machine. Say relational is the default and NoSQL needs a reason.
2. "What do you give up with NoSQL?" — Enforced schema, joins, and often strict consistency. Those guarantees move into your application.
3. "Is NoSQL faster than SQL?" — Depends on the question shape. Faster for whole-record fetches, usually slower for aggregate analysis across relationships.

Recap

NoSQL drops schema enforcement, joins and sometimes strict consistency to gain flexibility and horizontal scaling — so relational stays the default unless one of those trades genuinely pays.