SQL vs NoSQL

Why it matters

"SQL or NoSQL?" is a question interviewers ask to hear your reasoning, not your answer. The labels hide four separate trade-offs, and most of the famous arguments for one side are arguments about one of those four. Separating them lets you say exactly which property you need and which you are giving up, which is the whole skill.

The idea

SQL databases (relational) store typed rows in tables with a fixed schema, relate them with keys, and offer joins and ACID transactions through a declarative query language. NoSQL is a grab bag of everything else, document, key-value, wide-column and graph stores, united mostly by dropping some relational guarantees to gain something: write throughput, flexible shape, or horizontal scale.

The four real trade-offs

Axis	Relational	Typical NoSQL	What it costs you
Schema	Enforced on write: every row conforms	Enforced on read: the application interprets whatever is stored	Flexibility now versus a migration problem later, when five shapes of the same record coexist
Relationships	Normalised tables joined at query time	Embedded or duplicated data, joins done in the application	Join flexibility versus read speed and the burden of updating duplicates
Consistency	ACID transactions across rows and tables	Often single-document atomicity, eventual consistency across replicas	Correctness guarantees versus availability and throughput under partition
Scaling	Vertical first; read replicas; sharding is manual and hard	Horizontal by design: partition key spreads data across nodes	Simplicity of one node versus the operational model of a cluster

The line has blurred

Postgres stores and indexes JSON documents (jsonb), MySQL does too, and both run billions of rows on a single well-tuned primary. MongoDB has multi-document transactions; DynamoDB has transactions and strongly consistent reads; "NewSQL" systems (Spanner, CockroachDB, TiDB) give relational semantics over horizontally sharded storage. So the real question is rarely the label and almost always: which of the four axes do you need to be on which side of, and does the store you like let you be there?

When each side genuinely wins

Relational wins when queries are varied and unpredictable, when integrity constraints prevent real-world bugs (an order must have a customer), when transactions span entities, and when the team benefits from a mature ecosystem of tools, ORMs and analysts who speak SQL. NoSQL wins when write throughput or data volume exceeds what one primary can take, when the data is naturally one self-contained document read whole, when records legitimately have different shapes, or when a specific shape (graph traversal, time windows) has a purpose-built store.

Arguing the choice

Weak argument: "NoSQL scales." Strong argument: "Our write rate will be 50,000 events per second with reads only by device id, so a partitioned key-value model fits and relational joins add nothing." Weak: "SQL is more mature." Strong: "Orders, payments and inventory must change together, and analysts will query them in ways we cannot predict, so a relational source of truth is the lower-risk choice." The pattern is always: name the access pattern, name the axis, name the cost you accept.

Trade-offs

Relational buys correctness and query flexibility and pays in write scalability and schema ceremony. NoSQL buys throughput, flexible shape and horizontal scale and pays in application-side joins, duplicated data and weaker cross-entity guarantees. Mixed architectures pay in synchronisation. None of these costs are hidden if you ask the four questions first.

In an interview

Answer with the axis, not the label: "Relational for the core because the entities are related and must change transactionally; schema on write catches bugs early. Events go to a wide-column store because they are write-heavy, read by key and never joined. If we outgrow a single Postgres primary we shard by tenant or move to a distributed SQL system before giving up relational semantics."