SQL vs. NoSQL — stop asking the wrong question

Two teams build the same app. One picks SQL. One picks NoSQL. Six months later, one team is rewriting their whole data layer — and it's not because they picked the wrong database. It's because they asked the wrong question.

Everyone fights about which one is faster, or which one scales. That's the wrong fight. By the end of this you'll know the one question that actually decides it, and why three things you've heard about SQL and NoSQL are just wrong.

Prefer to watch? Full walkthrough with the JOIN-vs-document animation:

The wrong question

"Which one is faster?" "Which one is modern?" "Which one scales?"

None of these pick your database. Speed and scale depend on how you use a database, not on which logo you chose. You can make either one fast, and you can make either one fall over.

The right question

What shape is your data — and how will you read it back?

Answer that, and the database almost picks itself. Here's what that means.

SQL: a relational database

In SQL, your data lives in tables — rows and columns, like a spreadsheet with rules. You define the shape up front. That's the schema.

The superpower is the JOIN. You keep users in one table and orders in another, then stitch them together on the fly to answer almost any question:

SELECT u.name, count(o.id)
FROM users u
JOIN orders o ON o.user_id = u.id
GROUP BY u.name;

"Every user, and how many times they ordered." You never designed for that query — SQL answers it anyway. That flexibility is the whole point of a relational database.

But it has a price. Your data is split across tables (that's normalization), so to read one thing back, the database has to stitch those tables together on every read. Fine at normal size. So what does NoSQL do differently?

NoSQL isn't one thing

First, an important correction: NoSQL isn't a single kind of database. It's a family. The four categories you'll usually see are document, key-value, wide-column, and graph databases.

They share one idea: you model your data around how you read it. Store together what you read together.

So instead of separate users and orders tables, you store one document — the user, with their orders inside it:

{
  "name": "Vlad",
  "orders": [
    { "id": 1, "total": 40 },
    { "id": 2, "total": 15 }
  ]
}

One read. Nothing to stitch. It's already assembled.

Same question, two shapes

That's the core difference. Ask "give me this user and their orders":

• SQL joins two tables at read time.
• NoSQL hands you a document that was already built that way.

Same answer, different shape. And that's the whole trade. The document is faster — for the read you planned. But now ask a new question: "every order over $40, across all users." In SQL that's one line. In your documents, that data is buried in a thousand separate places, because you didn't store it that way.

That's the trap that kills projects. You pick the shape for today's question. Then the product grows, the questions change — and the shape can't. That's the team rewriting everything.

Three myths, killed

Three things you've probably heard push people toward the wrong choice.

Myth 1 — "NoSQL has no schema"

False. The schema didn't disappear — it moved into your application code. Every read still assumes a shape; you just gave up the database checking it for you.

This even has a name: schema-on-read. As Martin Fowler puts it, a "schemaless" store still has an implicit schema — the structure your code relies on when it reads the data — instead of an explicit one enforced by the database. "Schemaless" doesn't mean no schema. It means you own it now.

Myth 2 — "SQL can't scale"

Also false. Postgres runs massive production workloads, and you'll hit product problems long before it's your bottleneck. And when you genuinely outgrow a single node, distributed SQL exists now — CockroachDB, Google Cloud Spanner, and Vitess all give you horizontal scale without giving up SQL.

Myth 3 — "NoSQL is faster"

Only for the pattern it was built for. Ask it something off-pattern and it's slower — or it just can't answer without loading everything and filtering in your app. Fast isn't a property of the database. It's a property of the match between your data's shape and your query.

So when do you use each?

• Relationships that matter, and questions that will change → go relational (SQL).
• One known access pattern, at huge scale → that's where NoSQL wins.
• And you're allowed to use both — plenty of systems put a relational database next to a key-value cache or a document store, each for what it's good at.

For most apps starting out, the boring answer is the right one: start with Postgres, and reach for NoSQL when you have a real, specific reason — not a vibe.

The takeaway

Stop asking which one is better. Ask what shape your data is, and how you'll read it back — and the database picks itself.

What made you reach for NoSQL last time — the scale, or the schema? Drop it in the comments — I read them.

---

I make Vlad's Stack — how the tools you use every day actually work, for people who write code. Full video walkthrough is above.