Stop 07 · NoSQL DatabasesTopics · 1/12

NoSQL vs SQL

In short

SQL isn't the only way to store data. NoSQL databases trade some of SQL's rules for flexibility and easier scaling. Knowing that trade helps you choose, instead of following hype.

The broad comparison between schema-flexible NoSQL databases (document, key-value, wide-column) and structured relational SQL databases — each with different trade-offs for consistency, flexibility and scale.

The blob compares a steel thali with fixed compartments and an overflowing cloth bag.

Think of it like this

Steel thali vs cloth jhola

A steel thali has fixed compartments: dal here, rice there, nothing else fits. Neat and predictable, like SQL tables. A cloth jhola takes whatever you throw in, any shape, any size, like NoSQL documents. Great for a messy market run, worse for serving a tidy meal.

Watch it happen

Two ways to store data

SQL

Fixed schema, tables and joins
Strong ACID transactions by default
Usually scaled with a bigger server first

NoSQL

Flexible shape for each record
Data shaped around your queries
Built to spread across many servers

Default to SQL for structured, related data. Reach for NoSQL when record shapes vary a lot or one access pattern needs huge scale.

The big ideas

What you need to know

Four main families

Document (MongoDB), key-value (Redis), wide-column (Cassandra) and graph (Neo4j). Each suits a different job.

Schema in your code

NoSQL lets each record differ. Your app, not the database, decides what a valid record looks like.

Built to spread out

Many NoSQL systems split data across machines by a key, so they grow by adding servers.

Fewer joins, more copies

NoSQL often duplicates data so one read gets everything. Updates then have to touch several places.

See it in code

Walk through the code

1// SQL: three tables, joined when you read2// users(id, name)   orders(id, user_id)   items(order_id, dish)3 4// MongoDB: one document holds the whole order5{6  _id: ObjectId("6721f0c2a1b2c3d4e5f60718"),7  user: { id: 7, name: "Riya" },8  items: [9    { dish: "Masala dosa", qty: 2 },10    { dish: "Filter coffee", qty: 1 }11  ],12  total: 260,13  placedAt: ISODate("2026-10-27T09:30:00Z")14}

1/3In SQL, an order is spread over tables and joined back together when you read it.

Same order, two shapes. Neither is wrong; they suit different read and write patterns.

Save yourself the pain

Common mistakes

Oops

Picking MongoDB because 'SQL doesn't scale'.

Do this instead

Postgres and MySQL run very large apps. Choose by data shape and access pattern, not by myths.

Oops

Thinking NoSQL means there's no schema at all.

Do this instead

There's always a schema; it just lives in your code. Validate it, for example with Mongoose or JSON Schema.

Your mission

One app, two designs

~20 min

Quick check

Which job suits a document database better than SQL?

Go deeper

1List 3 scenarios where NoSQL fits better and 3 where SQL fits better.
2Compare how the same data (e.g. a blog post with comments) is modeled in each.
3Learn that most real systems use both — polyglot persistence — rather than picking one exclusively.