SQL vs NoSQL

In one line

The decision matrix: joins/transactions/flexibility vs scale/schema/consistency — and the honest 'mostly SQL' answer.

0/10 · 0%

Think of it like this

Choosing between a bank locker (SQL: strict rules, verified, but slower and rigid) and a big self-storage warehouse (NoSQL: fast, flexible, store almost anything, but fewer guarantees about how it's organized).

Key ideas

01
SQL strengths: joins, ACID transactions, rich query (GROUP BY, window fns), mature tooling, strong guarantees.
02
SQL limits: vertical scaling ceiling, schema rigidity, join cost at enormous scale.
03
NoSQL = four families (document, key-value, wide-column, graph) — each trades something SQL has.
04
Document (Mongo): flexible schema, embed-nested data, natural fit for profile-ish data; loses joins/transactions across docs (multi-doc ACID exists but costs).
05
Key-value (Redis, Dynamo): O(1) by key, huge scale, no queries beyond key access.
06
Wide-column (Cassandra, Bigtable): partition-key tables at planetary scale, eventual consistency by default.
07
Graph (Neo4j): relationship traversal — friends-of-friends, recommendations, path finding.
08
The honest interview answer: 'start with Postgres; move a specific access pattern to NoSQL only when the numbers say so'.

Java / Spring map

→
Spring Data JPA / JDBC for SQL; spring-data-mongodb / redis / cassandra each slot in per store.

Code & diagrams

SqlVsNosql.mdmarkdown

The decision cheat-sheet.

Start: PostgreSQL/MySQL (ACID, joins, mature ops)

Move to / add when:
- Reads are always by key, schema varies  → DynamoDB/Redis (key-value)
- Profile/nested data, flexible schema   → MongoDB (document)
- Planetary write scale, time-series-ish  → Cassandra (wide-column)
- Deep relationship traversal            → Neo4j (graph)

The pattern that actually ships:
- Canonical+transactions → Postgres
- Hot reads by key      → Redis (cache) or DynamoDB
- Event stream          → Kafka, not a DB
- Full text / search    → Elasticsearch

Explain without notes

An interviewer says 'we'll use MongoDB for everything.' Give the two questions you'd push back with.

Practice

Take 'chat app': which store for messages, which for user profiles, which for presence? Justify each.

Trade-offs

↔
Polyglot persistence is powerful and operationally expensive — every extra store is a new failure mode.

Run it in production

You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:

Stateful · PostgreSQL essentials

MVCC, VACUUM, roles, and the SQL vs NoSQL families, from the operator's side.

AWS · DynamoDB & ElastiCache

Managed key-value storage and caching.

Completion checklist

I can map a workload to SQL/key-value/document/wide-column/graph and say why.

Back to phase

Command Palette