SQL vs MongoDB — Kab Kaun Sa?

Code examples

Example 1 — The same question, both languages

// SQL (from DB.1)
SELECT name, marks FROM students WHERE marks >= 90;

// MongoDB (from MG.4)
db.students.find({ marks: { $gte: 90 } }, { name: 1, marks: 1, _id: 0 })

What it does: Identical question — the 90 club — asked of the same five students in both worlds. SQL names columns to return; MongoDB's projection does the same job. Compare the two answers below: the facts are identical; only the packaging differs.

What you will see:

+-----------+-------+
| name      | marks |
+-----------+-------+
| Sara Khan |    92 |
| Hira Shah |    95 |
+-----------+-------+
2 rows in set

[ { name: 'Sara Khan', marks: 92 }, { name: 'Hira Shah', marks: 95 } ]

A grid of rows versus a list of small documents. Neither answer is "more correct" — this is the whole comparison in miniature: SQL answers in tables; MongoDB answers in records that resemble the objects your code already uses. Pick the packaging your app thinks in.

Example 2 — Connected data: JOIN vs the document way

// SQL (from DB.5) — reconnect two tables at question time
SELECT students.name, fees.amount, fees.status
FROM students
LEFT JOIN fees ON students.id = fees.student_id;

// MongoDB — the fee lives with its own document; $lookup visits the neighbour
db.fees.find()

What it does: September's fees (from DB.5): Ali, Sara and Bilal paid; Usman's is pending; Hira has no fee record at all. SQL reconnects the two tables at question time — the LEFT JOIN keeps Hira visible with NULL. MongoDB keeps fees as their own small documents carrying a studentId reference, joining only when a question truly crosses the border (the full $lookup is MG.8's lesson).

What you will see:

+-------------+--------+---------+
| name        | amount | status  |
+-------------+--------+---------+
| Ali Raza    |   5000 | Paid    |
| Sara Khan   |   5000 | Paid    |
| Bilal Ahmed |   4500 | Paid    |
| Hira Shah   |   NULL | NULL    |
| Usman Tariq |   5000 | Pending |
+-------------+--------+---------+
5 rows in set

[
  { _id: ObjectId('650000000000000000000201'), studentId: ObjectId('650000000000000000000001'), month: 'September', amount: 5000, status: 'Paid' },
  { _id: ObjectId('650000000000000000000202'), studentId: ObjectId('650000000000000000000002'), month: 'September', amount: 5000, status: 'Paid' },
  { _id: ObjectId('650000000000000000000203'), studentId: ObjectId('650000000000000000000003'), month: 'September', amount: 4500, status: 'Paid' },
  { _id: ObjectId('650000000000000000000204'), studentId: ObjectId('650000000000000000000005'), month: 'September', amount: 5000, status: 'Pending' }
]

Same truth, two philosophies. The SQL answer is one ready-made report table — Hira's NULL shouting no record. The MongoDB answer is the raw material: four honest fee documents, and Hira's absence visible only when you go looking (MG.8 shows how $lookup makes her absence speak). If the app prints fee reports all day, SQL's way is home. If the app mostly reads one student at a time, documents win.

Example 3 — Change arrives: add an email field

// SQL — one ceremony, every row changes together
ALTER TABLE students ADD COLUMN email VARCHAR(100);

// MongoDB — one document grows, the rest are untouched
db.students.updateOne(
  { name: 'Ali Raza' },
  { $set: { email: 'ali.raza@example.com' } }
)

What it does: The school app now collects emails. In SQL the table itself must change first — one ALTER TABLE gives every row an (empty) email column, then data fills in. In MongoDB, Ali's document simply grows a field the day Ali provides one; the other students gain theirs whenever they provide theirs — no ceremony, no empty column carried by all.

What you will see:

Query OK, 0 rows affected

{ acknowledged: true, matchedCount: 1, modifiedCount: 1, upsertedId: null, upsertedCount: 0 }

Neither is free: SQL pays the cost once, up front, and gains a guarantee — every student row has an email slot, forever. MongoDB pays nothing today, and the cost arrives later as a question — which documents have email at all? ($exists from MG.4 is the answer tool). Ceremony buys certainty; flexibility buys speed. Mature developers name the price out loud before choosing.