SQL vs NoSQL

The problem

Relational databases are battle-tested but can be hard to scale horizontally. When do you reach for something else?

The idea

SQL gives structure, relationships, and ACID transactions. NoSQL trades some of that for horizontal scale and flexible schemas.

How it works

The real axis is access pattern, not "scale". SQL gives a normalized schema, joins, and ACID — model relationships once, query them flexibly. NoSQL families denormalize for a known pattern: key-value (Redis/Dynamo) for point lookups, document (Mongo) for nested aggregates, wide-column (Cassandra) for huge writes on a known partition key, graph (Neo4j) for traversals. NewSQL (Spanner, CockroachDB) now offers horizontal scale with SQL/ACID, eroding the old "pick one" framing.

The tradeoff

SQL scales reads easily (replicas) but writes/size eventually force sharding, which surrenders cross-shard joins and transactions anyway. NoSQL scales out natively but you model for one query shape up front — a new access pattern can mean a re-model or a second copy of the data. Many systems go polyglot: Postgres for core entities, a KV store for sessions, a search index alongside.

In the wild

Use Postgres until it hurts; reach for Cassandra/Dynamo for massive write volume or simple access patterns.

Interview deep dive

Flow

1. List the top queries and their access patterns first.
2. Default to SQL for relationships and transactional integrity.
3. Reach for the NoSQL family that matches a specific hot pattern.
4. Consider NewSQL when you need both SQL and horizontal scale.

Watch for

• "NoSQL for scale" is a smell — choose by access pattern.
• NoSQL denormalization optimizes one query and punishes the rest.
• Sharded SQL loses joins/transactions too — scale isn't free either way.

Interviewer trap

Justify the store from the query shape, and note NewSQL closes the old SQL-vs-scale gap.

Related Academy