SQL and NoSQL

Pick by access pattern and consistency need, not by which is fashionable.

The idea

The SQL-versus-NoSQL question is asked as if it were about scale. It is mostly about access pattern and consistency requirements, and getting that framing right is most of the answer.

Relational databases store normalised rows and let you ask questions you did not anticipate. Joins mean you do not have to know your queries in advance; transactions mean multi-row changes are atomic; constraints mean the database refuses to hold invalid data. Modern Postgres handles far more load than most systems will ever see, and "just use Postgres" is the right answer more often than the question implies.

NoSQL is not one thing. Each family trades a different piece of that away:

Document stores drop joins in exchange for a record you read whole.
Key-value stores drop queries entirely in exchange for speed.
Wide-column stores drop flexible querying in exchange for write throughput at a scale relational systems struggle with.
Graph stores are not a compromise at all — they are the right tool when relationships are the data.

The honest decision procedure: start relational. Move a specific workload elsewhere when it has a specific, measured reason — write volume a single primary cannot absorb, a document shape that fights normalisation, or a traversal that a join expresses badly.

Two things worth being precise about in an interview. Denormalisation is a choice, not a property of NoSQL — you can denormalise in Postgres and normalise in Mongo. And "NoSQL scales better" is imprecise: it usually means the store made partitioning easy by removing joins and cross-shard transactions, which is a trade you can also make deliberately in a relational system.

Walkthrough

No walkthrough for this topic yet — the guided exercises below run the same way.

When to reach for it

Relational when data has relationships, when you need transactions, or when future queries are unknown — which is nearly always at the start.
Document when a record is read and written whole and rarely joined to anything.
Key-value for sessions, caches, counters, and anything reached only by primary key.
Wide-column for write volumes in the hundreds of thousands per second with a known query shape.
Graph when the queries are many-hop traversals rather than lookups.

Rather than the obvious alternative

Reaching for NoSQL to scale

A relational database with correct indexes, read replicas and a cache handles very large systems. Move a workload out when you can name the specific limit it hit — not in anticipation.

Using one store for everything

Polyglot persistence is normal: Postgres for the core data, Redis for sessions, a search index for search. The cost is operational, and it is often worth paying.

Which database?

Answer for a system you are actually designing. Every option says where it leads before you pick it — the follow-up in an interview is always "why not the other one?".

Do the records reference each other in ways you will query across?

This is the first question because it is the one that rules things out. Everything else is a performance argument; this is a correctness one.

Key terms

SQL vs NoSQL: Relational schemas and joins versus flexible documents and denormalisation.
Indexing: A secondary structure making lookups fast without scanning.
Normalization: Structuring data to remove redundancy.
N+1 queries: Fetching a list, then querying once per item.
Busy database: Pushing work into the database that the application could do.

How to spot it

The interviewer describes the data model — that is the input to this decision.
The question mentions transactions, money, or inventory, which points hard at relational.
Write volume is stated in the hundreds of thousands per second.
Queries are described as "find everything connected to X within three hops".

Where it goes wrong

Choosing by popularity rather than access pattern

The answer "we would use MongoDB" with no reference to how the data is read is the one interviewers are listening for.

Assuming NoSQL means no schema

It means the schema is enforced in your application instead of the database. It has not gone away; it has moved somewhere with fewer guarantees.

Ignoring the index

Most "the database is slow" stories are a missing index, in either family. Say what you would index and why.

Forgetting operational cost

Every additional store is another thing to back up, monitor, upgrade and be paged for at 3am.