What NoSQL actually is
NoSQL databases exist because of the wall you just studied: one SQL leader has a write ceiling, and sharding SQL by hand (lesson 5-1) is real surgery. In the late 2000s, web companies stuck at that wall built databases that shard themselves, and the family got the name NoSQL: databases that give up some of SQL's features in exchange for easier horizontal scaling. The two members worth knowing first:
- Key-value stores (Redis, DynamoDB): a giant dict. Get and set by key, blazing fast, no joins, no queries by other columns
- Document stores (MongoDB, DynamoDB again): values are JSON-like documents, queryable by fields, flexible per-row structure
What they typically give up, compared to the SQL you learned:
- Joins: you fetch related data yourself, or duplicate it into the document
- Multi-row transactions: all-or-nothing updates across rows are limited or absent
- A fixed schema: flexible, but typos and drift become your problem
What they buy: most were built sharded, with consistent hashing inside, so scaling out is turning a dial instead of the unit 5 surgery you just studied.
The honest decision table
| Situation | Reasonable default |
|---|---|
| Almost every new app | SQL (Postgres, MySQL) |
| Money, inventory, anything needing transactions | SQL |
| Simple key-based access at enormous write scale | Key-value or document store |
| Caches and sessions | Redis |
| Flexible or fast-changing record shapes | Document store |
The honest part: SQL scales much further than the internet claims. One well-indexed Postgres box with replicas handles millions of users, and sharded SQL runs some of the largest sites alive. Most NoSQL migrations at small companies were fashion, not need, and the teams missed joins within a month.
Pick SQL until you can name the specific limit you are hitting, in numbers, like writes per second beyond one leader (lesson 5-1) or truly key-only access patterns.
Quiz
A payments startup stores account balances and transfers. Which database property makes SQL the safe choice here?
Problem
Your SQL leader tops out around 20,000 writes/sec. The app now sustains 60,000 writes/sec of simple by-key session updates that need no joins and no transactions. You will split this workload out of SQL. To handle the write volume with headroom for one node's failure, at least how many equally-loaded shard nodes do you need? (Each node handles 20,000 writes/sec.)