NoSQL families
Ledger's group chat outgrew the expenses database. Key-value, document, wide-column, graph — each NoSQL family is fast at the questions it was built for and gives something up to get there. Which one fits, and when does the relational default still win?
13 minMediumStation: NoSQL familiesMembers lesson
Membership isn’t open yet. The free lessons are open — 16 of them.
- Relational databases & indexes
- NoSQL families
- Access patterns & denormalization
- Read replicas
What you'll be able to do
- 1Choose a relational, key-value, document, wide-column or graph store for a workload from how its data is read and written.
- 2Explain what a NoSQL store gives up compared with a relational database — ad-hoc queries, joins, wide transactions — and what it gains.
- 3Predict what happens when an app asks a NoSQL store a question its keys weren't designed for.
Inside the lesson
- steps
- 11
- questions
- 11
- simulations
- 0
Step 1 · The setup
Ledger — the shared-expenses app from the last stop — added a chat thread to every group, so people can argue about who paid for the pizza. The chat took off. Expenses arrive a few times a day per group; messages arrive by the hundred. The messages table now holds many times more rows than the expenses table, and it keeps growing.
Almost every read is the same question: the latest 50 messages in this group. Someone on the team says: "Chat doesn't belong in the expenses database — let's use a NoSQL store." Another asks: "Which one? And what do we lose?"
Steps 2–11 are for members