Built for records that don't all share one shape, and for more people than one machine can serve. Documents instead of rows, thousands of machines instead of one, found by their key, and the choice between agreeing first and answering now.
Every product in a shop needs its own facts, and a relational table wants every row to have the same columns. That is the first problem NoSQL was built for. The second is size: a million people at once is more than one machine can serve.
A document database stores each product as its own document, with the fields it needs and nothing else. The records are split across thousands of machines, each found by its key, so a request goes straight to the right one. Spreading records means keeping copies, which raises the question the video pauses on: change your address on one copy, ask another a moment later, and which address comes back? The database has to choose between agreeing first and answering now. Most let you pick per request, and Amazon chose answering now for its shopping cart.
That suits catalogues, profiles, carts and feeds. It doesn’t suit a bank transfer, which is why NoSQL sits beside relational databases rather than replacing them.
Every claim was checked against MongoDB’s, Cassandra’s and DynamoDB’s own documentation and Amazon’s 2007 Dynamo paper in September 2026. No product is recommended. This is an independent explainer, not affiliated with any vendor.
Transcript
Every product in a shop needs its own facts. A phone has a screen size, a shirt has a sleeve length, a book has an author. A relational table wants every row to have the same columns, so a catalogue like that ends up with hundreds of columns, and most of them empty.
A relational database has a rule that every record in a table shares one shape. A document database drops that rule. Each product becomes its own document, with the fields that product needs and nothing else, and two documents in the same collection don't have to match.
Shape was one problem, and size was the other. A relational database was built to live on one machine, and a million people at once is more than one machine can serve.
So the records are split across thousands of machines, each holding its own part. A request goes straight to the machine that holds the record, and to serve more people, you add more machines.
So how does it find one record among thousands of machines? Every document has a key, such as a customer number. The database turns that key into a number that names the machine, so a request by key goes straight there. Ask by anything else, and every machine has to be searched, which is why the key you choose matters.
Spreading records across machines means keeping copies. Say you change your address, and the change lands on one copy. A moment later, a different copy is asked for your address. Which address does that copy give back?
For a moment, that copy may still hold the old address, so the database has to choose between two things. It can wait until every copy agrees before answering, or it can answer at once with what it has and catch up later.
Most NoSQL databases let you pick per request. Amazon chose answering at once for its shopping cart, because a cart that never refuses mattered more than one that was always exact.
Documents and many machines suit catalogues, profiles, shopping carts and feeds. A bank transfer still wants every copy to agree before anyone is told, which a relational database does as standard. That is why NoSQL sits beside relational databases rather than replacing them.
NoSQL stores documents instead of rows, on thousands of machines instead of one, each found by its key. It was built for records that don't all share one shape, and for more people than one machine can serve.
Found this useful?
Subscribe for the next one, or tell me what you want explained. I take requests.
