Reference · Cheat sheet

The document model

Lesson 0001 distilled — the document is the unit of storage, atomicity, and schema design, and everything that follows. Built to print.

From lesson 0001Context: MongoDB current (7.0/8.0+)

The keystone

A document (BSON — binary JSON, extra types) is the unit of storage, atomicity, and schema design — all three.

It's a tree: fields can be nested documents and arrays. Documents live in a collection (≈ table, but schema-free).

Hard facts

_id = primary key, unique per collection; auto-set to an ObjectId if omitted.

16 MB max per document (guards RAM + bandwidth). Bigger → GridFS or reference out.

The modeling rule

Data accessed together is stored together. Model to your access pattern.

Embed by default → read one entity = one document lookup (no join). Reference (store an _id) when data is large, unbounded, or accessed independently.

Atomicity boundary

Single-document write = atomic, even across many fields/nested arrays — no transaction needed.

Multi-document atomic = needs a distributed transaction (costs more; often avoidable by embedding).

MongoDB vs relational

AspectPostgres/InnoDBMongoDB
Unitrowdocument
Schemafixedflexible
Relatenormalize + joinembed / reference
Read entityjoin tablesone document
Atomic ontransactiondocument

See it later (mongosh)

db.posts.insertOne({…embedded…})_id auto-created.

One updateOne with $push+$set changes an array and a nested field — atomic, no txn.