1.Every Seller Gets Their Own Shape

Sarah opens a blank project. No CREATE TABLE, no column list to argue over first. Just one collection — listings — and a decision from the checkpoint she's carrying straight into this Act: each listing gets to be its own shape.

She types the first real record straight in. Not a row. A document.

GreenMart's new database is MongoDB — the first real, specific product this course actually names, after a whole Act spent on the concept it belongs to. It's a document database: instead of rows inside a fixed-column table, data lives as documents — self-contained records that look a lot like the JSON objects Sarah already knows from building the storefront's own frontend.

A collection is where documents of a similar kind live — listings, in this case — but "similar kind" is a much looser promise than a relational table makes. Nothing forces every document in listings to share the same fields. Each one just needs to make sense on its own.

Worth answering directly, since the name doesn't explain itself: why "document"? Look back at the listing above — every single value in it carries its own field name, written right there next to it: price: 8.99, voltage: "20V". A relational row doesn't do that. A row is just a sequence of bare values — "Fast Charger", 8.99, "20V" — and what each position actually means lives somewhere else entirely, in the table's own column definitions, not on the row itself. The listing above needs nothing outside itself to be understood; it labels its own data. That JSON object, exactly as written — self-labeled, self-contained, nothing external required to make sense of it — is the document. Not a row converted into JSON. Not a wrapper around the real data. The object itself, in full, is the document.

Under the hood, MongoDB doesn't store plain text JSON — it stores BSON (Binary JSON), a binary-encoded format that covers everything JSON can express, plus a few types JSON itself doesn't have (real dates, binary data) and faster for the database to read and traverse than parsing text every time. Sarah never writes BSON by hand — she writes JSON-shaped documents, and MongoDB handles the binary encoding underneath.

A document's individual key-value pairs are its fields — price, voltage, size — the same idea as a column, except a field only exists on the documents that actually use it. A field's value can also be another whole document nested inside it (a nested document — e.g. a dimensions field holding its own { length, width, height }), or a list of values (an array — e.g. tags: ["electronics", "charger"]). Neither of those has a clean equivalent in a single relational row.

This is schema flexibility in practice — no upfront column list, and every document can carry only what it actually needs. It doesn't mean "anything goes forever, no rules ever": MongoDB also supports schema validation — optional rules a collection can enforce (a field must exist, must be a certain type, must match a pattern) applied when GreenMart is confident enough about a shape to actually require it. Flexible-by-default and validated-when-you-choose-to are both true at once; one doesn't cancel out the other.