Why NoSQL

The Original Motivation: Scale

 mid-2000s reality at web giants:
 - relational vertical scaling hit ceilings (write IOPS, RAM)
 - sharding MySQL by hand = enormous operational pain
 - availability mattered more than perfect consistency
   (users prefer "site works, slightly stale" over down)

 answer: purpose-built stores that RELAX relational guarantees
 in exchange for horizontal scale + availability:

 Dynamo (Amazon):  key-value, eventual consistency, always-writable
 Bigtable (Google): wide-column, massive write throughput

The Second Motivation: Data Shape

 relational assumes uniform rows. real data often isn't:

 - nested documents (product with variants, specs, media)
 - sparse attributes (products sharing few common fields)
 - rapidly evolving shapes (startup schema churn)
 - graph-shaped relationships (social networks)
 - time-series (metrics, events — append-only)

 storing JSON blobs in TEXT columns fights the database.
 document stores make the shape FIRST-CLASS instead.

The Trade Space

 every NoSQL family trades SOME relational property:

 GIVEN UP                     GAINED
 ──────────────────────────────────────────────────────
 joins/ad-hoc queries    →    predictable single-key speed
 global constraints      →    partition-tolerant writes
 strict schema           →    flexible/evolving documents
 strong consistency      →    availability under partitions
 SQL ecosystem           →    specialized performance profiles

 no free lunch exists — only different lunches.
 choosing well = knowing which property your workload
 doesn't actually need.

The Families Preview

 KEY-VALUE      Redis/DynamoDB     fastest simple access; cache/session
 DOCUMENT       MongoDB/CouchDB    nested objects; per-doc queries  
 WIDE-COLUMN    Cassandra/Bigtable  huge writes; time-series/partitions
 GRAPH          Neo4j              relationship traversal depth
 TIME-SERIES    InfluxDB/Timescale metrics/events at scale
 SEARCH         Elasticsearch      full-text, facets, aggregations
 VECTOR         pgvector/pinecone  embeddings for AI similarity

 each gets dedicated lessons; this one is about WHY they exist:
 different workloads have different bottlenecks,
 and one size stopped fitting all at web scale.

The Honest Modern Picture

 the 2010s "NoSQL vs SQL" war ended in convergence:

 - Postgres gained JSONB (document), scale-out options,
   full-text search, vectors — absorbing many use cases back
 - NoSQL systems added joins, transactions, SQL layers
 
 today's question isn't ideology but fit:
 default to Postgres until a SPECIFIC measured need
 (write throughput, access pattern simplicity, global distribution)
 justifies a specialist store.

Interview Framing

“Why not just Postgres?” scored answers run workload-first: name the dominant access pattern, its scale numbers, THEN pick the family (“500k location pings/sec, keyed by driver_id, TTL’d → wide-column or KV fits; relational overhead buys nothing here”). Candidates citing “flexible schema” as primary reason get pushed on whether their data is truly schemaless — usually it isn’t.