SQL vs NoSQL

Two engineers. Same brief: build a social platform where users have profiles, write posts, and follow each other. Engineer A reaches for PostgreSQL. Engineer B reaches for MongoDB. Same data. Same features. Completely different experience building, querying, and scaling it. This lesson puts both solutions side by side — same problem, line by line — so you can see exactly where each one wins and where each one struggles.

The Data Model — Designing the Same Thing Twice

Before writing a single query, both engineers have to decide how to structure their data. This is where the philosophies immediately diverge.

Round 1 — Writing Data

The scenario: A new user signs up and immediately writes their first post with two tags. Let's see how many operations each system needs.

-- Operation 1: insert the user
INSERT INTO users (name, email, bio)
VALUES ('Priya', 'p@mail.com', 'Dev');

-- Operation 2: insert the post
INSERT INTO posts (user_id, body)
VALUES (1, 'Hello world!');

-- Operation 3: tag 1
INSERT INTO post_tags (post_id, tag)
VALUES (1, 'tech');

-- Operation 4: tag 2
INSERT INTO post_tags (post_id, tag)
VALUES (1, 'intro');

// One insertOne — everything together
db.users.insertOne({
  name:  "Priya",
  email: "p@mail.com",
  bio:   "Dev",
  posts: [{
    body: "Hello world!",
    created_at: new Date(),
    tags: ["tech", "intro"]
  }]
})

Round 2 — Reading Data

The scenario: Load a user's profile page — their name, bio, and their last 3 posts with tags. This is a page that gets loaded millions of times a day.

SELECT
  u.name, u.bio,
  p.body, p.created_at,
  pt.tag
FROM users u
JOIN posts p
  ON p.user_id = u.id
JOIN post_tags pt
  ON pt.post_id = p.id
WHERE u.id = 42
ORDER BY p.created_at DESC
LIMIT 3;

db.users.findOne(
  { _id: 42 },
  {
    name: 1,
    bio: 1,
    posts: { $slice: -3 }
  }
)

-- SQL result (multiple rows, needs client-side grouping):
name   | bio    | body              | created_at          | tag
-------+--------+-------------------+---------------------+------
Priya  | Dev    | Shipped v2 today! | 2024-01-15 14:22:00 | tech
Priya  | Dev    | Shipped v2 today! | 2024-01-15 14:22:00 | work
Priya  | Dev    | Hello world!      | 2024-01-10 09:00:00 | intro

-- MongoDB result (one object, ready to use):
{
  name: "Priya",
  bio: "Dev",
  posts: [
    { body: "Shipped v2 today!", tags: ["tech","work"], ... },
    { body: "Hello world!",      tags: ["intro"],       ... }
  ]
}

Round 3 — Changing the Schema

The scenario: Six months after launch, the product team wants a "verified" badge for trusted users. Engineer A and Engineer B both get the ticket at 9am. Here's how their day goes:

// MongoDB — mark a user as verified
// No migration. No ALTER TABLE. Just update the document.
db.users.updateOne(
  { _id: ObjectId("64f1a2b3c4d5e6f7a8b9c001") },
  { $set: { is_verified: true, verified_at: new Date() } }
)

Head-to-Head — 6 Criteria

Decision Tree — Which One Should You Use?

Run your project through this. Be honest with the answers — the most common mistake is answering based on what sounds exciting rather than what the data actually looks like.

Real Company Stacks — What They Actually Run

The best engineers don't pick one side. Here's proof — real companies running both SQL and NoSQL in the same product:

The pattern is clear: NoSQL handles the high-volume, flexible, fast-changing data. SQL handles the financial and relational core. They work side by side, not against each other.

Practice Questions — You're the Engineer

Quiz — You're the Architect