100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
MongoDB

Documents and Collections

How MongoDB structures data into documents and collections, including field types, embedding versus referencing, and the _id field.

MongoDB FoundationsBeginner9 min readJul 10, 2026
Analogies

Documents: The Basic Unit of Data

A MongoDB document is an ordered set of key-value pairs, similar to a JSON object, where values can be strings, numbers, booleans, dates, arrays, nested sub-documents, or even binary data. Every document requires a unique _id field within its collection; if you don't supply one, MongoDB automatically generates an ObjectId, a 12-byte value that encodes a timestamp, a random value, and a counter, making it unique and roughly sortable by creation time.

🏏

Cricket analogy: Every player registered with the BCCI gets a unique player ID the moment they're added to the system, the way MongoDB auto-assigns a unique ObjectId to every document that doesn't specify its own _id.

A collection is a named grouping of documents within a database, roughly analogous to a table, but without enforcing that every document share identical fields or types unless schema validation is configured. Collections are created implicitly the first time you insert a document into them, and MongoDB stores documents in a collection using an internal storage engine (WiredTiger by default) that also manages indexes defined on that collection to speed up queries.

🏏

Cricket analogy: A 'matches' collection can hold a T20 match document with a powerplay field right next to a Test match document with a follow-on field, since MongoDB doesn't force every cricket match record into identical columns the way a rigid spreadsheet would.

Embedding vs. Referencing

MongoDB gives you two main ways to model relationships: embedding related data as a nested sub-document or array inside the parent document, or referencing another document by storing its _id and performing a separate query (or a $lookup aggregation stage) to join the data. Embedding is preferred when the related data is always accessed together and doesn't grow unbounded, while referencing is preferred for data that's shared across many parents, updated independently, or could grow very large, such as comments on a popular post.

🏏

Cricket analogy: A player's career batting average is best referenced from a shared 'players' collection rather than embedded into every single match document, since it would otherwise need updating in thousands of places every time Rohit Sharma plays another innings.

Working with Arrays and Nested Fields

Fields inside a document can hold arrays of values or sub-documents, and MongoDB's query language lets you filter, update, and index into these nested structures directly using dot notation, such as querying 'address.city' or matching an element inside a 'tags' array. This nested querying is what makes embedding practical: you don't lose the ability to search inside embedded data the way you might expect if you were only used to flat relational rows.

🏏

Cricket analogy: Querying for any match where 'innings.wickets' includes a hat-trick is possible directly with dot notation, similar to how a scorer can flip straight to the wickets column of the second innings without unpacking the whole scorecard.

javascript
// A document with embedded sub-documents and an array
db.orders.insertOne({
  customer: { name: "Asha Rao", email: "asha@example.com" },
  items: [
    { sku: "SKU-101", qty: 2, price: 12.5 },
    { sku: "SKU-204", qty: 1, price: 39.0 }
  ],
  status: "shipped",
  createdAt: new Date()
})

// Query using dot notation into an embedded field
db.orders.find({ "customer.name": "Asha Rao" })

// Match a value inside an array field
db.orders.find({ "items.sku": "SKU-204" })

The maximum size of a single BSON document is 16 MB, which is why very large or unbounded arrays (like comments on a viral post) are usually modeled as a referenced collection instead of an embedded array.

Unbounded array growth inside a single document is a common design mistake: embedding thousands of growing sub-documents in one array can hit the 16 MB document limit and degrade write performance well before that limit is reached.

  • A document is an ordered set of key-value pairs, and every document needs a unique _id.
  • MongoDB auto-generates a 12-byte ObjectId as _id if one isn't provided.
  • A collection groups documents and is created implicitly on first insert.
  • Documents within a collection don't need identical fields unless validation is configured.
  • Embedding suits data always accessed together; referencing suits shared or independently growing data.
  • Dot notation lets you query and index into nested fields and array elements directly.
  • A single BSON document has a hard 16 MB size limit.

Practice what you learned

Was this page helpful?

Topics covered

#MongoDB#MongoDBStudyNotes#Database#DocumentsAndCollections#Documents#Collections#Unit#Data#StudyNotes#SkillVeris