SQL vs NoSQL — when to use what

SQL (relational) databases store data in tables with fixed schemas, relationships, and ACID transactions. NoSQL is a broad term for non-relational stores: document (MongoDB), key-value (Redis), wide-column (Cassandra), graph (Neo4j), each optimized for different access patterns.

High-level comparison

flowchart TB subgraph SQL["SQL (Relational)"] T[Tables, rows, columns] J[Joins, foreign keys] A[ACID transactions] end subgraph NoSQL["NoSQL"] D[Document: JSON-like docs] K[Key-Value: key → value] W[Wide-column: column families] G[Graph: nodes & edges] end

Aspect	SQL	NoSQL
Schema	Fixed, enforced	Flexible (doc) or simple (KV)
Transactions	Multi-row ACID common	Often single-doc or eventual consistency
Scaling	Vertical + read replicas; sharding complex	Horizontal sharding common (doc, KV, wide-col)
Query	Declarative SQL, joins	API/query by key, index, or graph traversal
Use cases	Structured data, reporting, consistency-critical	Flexible schema, high write throughput, cache, graph

When to use which

flowchart LR subgraph PreferSQL["Prefer SQL"] P1[Strict consistency] P2[Complex queries / joins] P3[Reporting, analytics] end subgraph PreferNoSQL["Prefer NoSQL"] N1[Schema evolution / flexible] N2[Very high write scale] N3[Cache, session, key lookup] N4[Graph relationships] end

Choose SQL when you need strong consistency, complex relations, and a clear schema. Choose NoSQL (and which type) when you need horizontal scale, flexible or nested documents, simple key access, or graph traversal — and can accept the trade-offs (e.g. eventual consistency, no joins).