SQL vs NoSQL#
"NoSQL" lumps together five very different storage paradigms; the only thing they share is "not a relational table". Pick by access pattern, not buzzword.
Side-by-side#
| Relational (SQL) | Document | Key-Value | Wide-Column | Graph | |
|---|---|---|---|---|---|
| Model | Tables, rows, FKs | JSON-like docs | Opaque key → value | Sparse multi-dim rows | Nodes + edges |
| Schema | Strict, declared | Flexible | None | Per-column-family | Property graph or RDF |
| Joins | First-class | Limited | None | None | Native traversal |
| Transactions | ACID multi-row | Single-doc usually | Single-key usually | Single-row | Varies |
| Scaling | Vertical primary; sharded with effort | Horizontal | Horizontal | Horizontal | Hard (NP partition) |
| Consistency default | Strong | Tunable | Tunable | Tunable | Strong (single node) |
| Examples | PostgreSQL, MySQL, SQL Server | MongoDB, DynamoDB JSON, Couchbase | Redis, DynamoDB, etcd | Cassandra, ScyllaDB, HBase | Neo4j, Neptune, JanusGraph |
Decision tree#
flowchart TB
Q[New service] --> A{Relationships<br/>and joins central?}
A -->|yes| SQL[Relational]
A -->|no| B{Single-key<br/>lookups dominate?}
B -->|yes, low latency| KV[Key-Value Redis or Dynamo]
B -->|no| C{Heavy<br/>graph traversal?}
C -->|yes| GR[Graph DB]
C -->|no| D{Petabyte-scale<br/>append-heavy time series?}
D -->|yes| WC[Wide-column Cassandra]
D -->|no| DOC[Document MongoDB]
classDef client fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
classDef edge fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
classDef service fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
classDef datastore fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
classDef cache fill:#fed7aa,stroke:#9a3412,stroke-width:1px,color:#0f172a;
classDef queue fill:#ede9fe,stroke:#5b21b6,stroke-width:1px,color:#0f172a;
classDef compute fill:#d1fae5,stroke:#065f46,stroke-width:1px,color:#0f172a;
classDef storage fill:#e5e7eb,stroke:#374151,stroke-width:1px,color:#0f172a;
classDef external fill:#fce7f3,stroke:#9d174d,stroke-width:1px,color:#0f172a;
classDef obs fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
class Q,A,B,C,D service;
class SQL,KV,GR,WC,DOC datastore;What you'll get asked#
- "Why SQL over NoSQL by default?" Relational + ACID is the most general, best-understood, and least-surprising store. Push to NoSQL only when scale or shape demands it.
- "When does Mongo actually fit?" Aggregating per-document data that doesn't join much (CMS, product catalog, user profiles). Schema flexibility for evolving payloads.
- "DynamoDB or Cassandra?" DynamoDB if you want serverless and SQL-compatible-ish query; Cassandra if you need on-prem or wide-row time-series at scale.
- "NewSQL?" Spanner / CockroachDB / TiDB / YugabyteDB give SQL semantics with horizontal scaling via Raft + sharding. Default choice for greenfield distributed OLTP.
Common mistakes#
- Picking NoSQL because "scale" without measuring whether one SQL primary suffices.
- Using Mongo as a relational store with embedded refs and emulated joins.
- Trying to model a graph in SQL with recursive CTEs past a few hundred K rows.
- Treating Redis as a primary database without a durable store behind it.
Related fundamentals#
FAQ#
When should I use SQL instead of NoSQL?#
Use SQL when you need joins, foreign keys, ACID transactions, and ad-hoc analytical queries. Modern Postgres handles JSON, full text, and vectors well enough to delay most NoSQL choices.
What are the main types of NoSQL databases?#
Document like MongoDB, key-value like Redis or DynamoDB, wide-column like Cassandra, and graph like Neo4j. They share little beyond not being relational tables, so pick by access pattern.
Is NoSQL faster than SQL?#
Sometimes, for the workloads they target. A key-value store beats SQL on point reads at huge scale, but SQL wins on complex joins and aggregations. Speed depends on shape, not category.
Can NoSQL databases do transactions?#
Most modern NoSQL databases support some transactions. DynamoDB, MongoDB, and CockroachDB offer multi-document transactions, but consistency, scope, and performance tradeoffs vary widely.
What is the biggest mistake when picking SQL vs NoSQL?#
Choosing NoSQL for scale reasons that never materialise. Postgres scales further than most teams realise, and migrating later is easier than recovering from poor data modelling in a wide-column store.