In this chapter
We'll meet the four NoSQL data models — Document, Key-Value, Wide-Column, and Graph — and see which kind of problem each one actually solves.
The Problem in Real Life
Sarah starts sketching. Not a fix for the Products table yet — just a list of every kind of data problem she can already see coming, now that GreenMart is opening up to outside sellers. A single listing with nested specs, sizes, and photos. A shopping cart that needs to be read and written constantly, in milliseconds. Truck sensor data (once the delivery fleet exists) arriving nonstop, thousands of readings a minute. And, further out, a referral program — who invited whom, who shares a payment method with whom.
Four very different problems. Sarah starts to notice they don't just need "no fixed columns." They need genuinely different shapes.
This isn't one alternative to a table. It's like four different ones.
Sarah
One Shape vs. Four Shapes
A single listing with nested fields
One electronics listing, with specs nested right inside it — a shape a document model was built to hold.
One fast lookup by a single key
A shopping cart or session token — just one key, one value, and speed that matters more than complex queries.
Millions of similar, fast-arriving rows
Sensor pings from a fleet of trucks, arriving nonstop — the shape wide-column stores were built to absorb.
Connections that matter as much as the records
Who referred whom, which accounts share a payment method — a shape only a graph makes easy to ask about.
The Four NoSQL Data Models
"NoSQL" is a family name, not one specific design. Underneath it, four data models cover almost everything a relational table struggles with — and each one exists because a different kind of problem doesn't fit neatly into rows and fixed columns.
| Model | Looks like | Good for |
|---|---|---|
| Document | A self-contained record that can nest its own fields, arrays, and structure | Data that's naturally one whole "thing" per record — a product listing, a user profile |
| Key-Value | A unique key pointing straight at a value, nothing more | Extremely fast, simple lookups — a session, a shopping cart, a cached price |
| Wide-Column | Rows that can each hold a different, very large number of columns | Massive volumes of similar, fast-arriving writes — sensor pings, activity logs |
| Graph | Nodes, plus the relationships between them, stored as data | Questions that are really about connections — referrals, fraud rings, recommendations |
Look back at chapter 1's problem through this lens: the seller-listing table wasn't wrong because it had columns. It was wrong because a document model — one self-contained, flexible record per listing — is what that specific problem actually needed, and a relational table can't bend into that shape without turning into the sparse, half-empty table Mike found.
The other three models solve problems GreenMart doesn't have yet, but will. A shopping cart that needs to be read and updated instantly, over and over, is a key-value problem. A delivery fleet streaming sensor data nonstop from every truck is a wide-column problem. A referral program, or a fraud investigation into a suspicious network of accounts, is a graph problem. None of these are "the same problem as the seller listings, solved differently" — they're genuinely different shapes of data, and each model exists because forcing all of them into rows and fixed columns creates a different kind of mess each time.
This course spends real time inside each one of these four models, one Act at a time — not because they're trendy names to know, but because each one is the direct, purpose-built fix for a problem the relational model was never designed to hold well.
Key Takeaway
NoSQL isn't one alternative to a table. It's four genuinely different shapes — and picking the right one starts with knowing which kind of problem you actually have.
Why This Matters
Everything from Act 2 onward is really this chapter, one model at a time, in real depth. Document databases fix the exact seller-listing problem chapter 1 opened on. Key-value stores show up the moment GreenMart's traffic and speed needs outgrow what a normal database read can keep up with. Wide-column and graph databases both wait for problems GreenMart hasn't hit yet — but when they do hit, this chapter is the reason Sarah will already know which shape to reach for.
Sarah has four shapes now, not zero. But which one fits a given problem isn't obvious from the data alone — it depends on what GreenMart actually needs to ask of it. That question — not "what does the data look like" but "what will I do with it" — is exactly where the next chapter starts.