Part 0 · 2 chapters · ~12 min
Why NoSQL Happened
The 2000s scale wall, the BigTable and Dynamo papers, the NoSQL taxonomy (key-value, wide-column, document, graph), what was oversold and what was real, the NewSQL correction, and an honest decision matrix.
1
Two papers and a movement
The real lessons of NoSQL outlived the hype: partition data deliberately, design for failure, choose consistency per use case, and model data for the queries you will run.
WHY NOSQL HAPPENED
the scale wall, two papers, and the correction
swipe the figure sideways, or tap expand for full screen
1/5
the scale wall
Mid-2000s web companies hit limits of single relational databases: write throughput, data size, and operating across data centres. Sharding MySQL by hand was painful.
writes and data outgrew one machinehand-sharded MySQL
2
The taxonomy and a decision matrix
| kind | examples | best at | poor at |
|---|---|---|---|
| key-value | Redis, DynamoDB (core), Riak | lookups by key at huge scale | queries by anything else |
| wide-column | Cassandra, ScyllaDB, HBase, Bigtable | massive write throughput, time series, multi-region availability | ad hoc queries, joins, transactions |
| document | MongoDB, Couchbase, Firestore | nested aggregates read and written together; flexible schemas | many-to-many relationships, cross-document invariants |
| graph | Neo4j, Neptune | multi-hop relationship queries (fraud rings) | bulk aggregations |
| relational | Postgres, MySQL | everything else, including JSON documents | extreme write scale on one node |