🍃 MongoDB Document Structure

What Is MongoDB?

MongoDB is an open-source NoSQL document database. Instead of splitting your data across tables of rows and columns, it stores each record as a single, flexible document — a structure that reads almost exactly like a JSON object. That single design choice ripples through everything else: the query language, how you model relationships, and how the database scales.

💡 Filing cabinet vs. spreadsheet. A relational database is like a spreadsheet: every row in a sheet must share the same rigid set of columns. MongoDB is more like a filing cabinet of folders — each folder (collection) holds documents, and each document can carry exactly the fields it needs, even if its neighbor carries different ones.

This flexibility is why MongoDB shines for content management, catalogs with wildly varying attributes, real-time analytics, rapidly evolving products, and IoT/time-series workloads. It is not a magic replacement for everything — heavily relational data with many joins and strict, database-enforced integrity often still fits a relational engine like PostgreSQL better. Most professional teams end up using both, choosing per workload.

The Document Hierarchy

MongoDB organizes data into four nested levels. Understanding this hierarchy is the fastest way to translate what you already know about relational databases:

MongoDB vs. Relational Databases

The document model is a genuine trade-off, not a strict upgrade. Here is a fair side-by-side so you can reason about which tool fits a given problem:

Documents and BSON Types

Although you read and write documents as JSON, MongoDB stores them on disk as BSON — Binary JSON. BSON is a binary-encoded superset of JSON that adds data types JSON lacks (dates, 64-bit integers, binary data, ObjectId, and more) and is designed to be fast to traverse. A single BSON document can be up to 16 MB; larger blobs belong in GridFS or object storage.

Here is a realistic user document that shows nesting, arrays, and several BSON types working together:

{
  "_id": ObjectId("5f8a76e910bd12b4e4c9a0f1"),  // ObjectId
  "username": "johndoe",                          // String
  "email": "john@example.com",                    // String
  "isActive": true,                               // Boolean
  "loginCount": 42,                               // Int
  "profile": {                                    // Embedded document
    "firstName": "John",
    "lastName": "Doe",
    "birthDate": ISODate("1990-07-15T00:00:00Z"), // Date
    "address": {                                  // Nested embedded document
      "city": "New York",
      "zipCode": "10001"
    }
  },
  "interests": ["programming", "hiking"],         // Array of strings
  "createdAt": ISODate("2020-10-17T09:34:33Z")    // Date
}

The _id Field and ObjectIds

Every document must have a unique _id field — it is the primary key. If you do not supply one, MongoDB generates an ObjectId automatically. An ObjectId is a 12-byte value, usually shown as a 24-character hex string, and it is cleverly structured:

• Globally unique: generated so different servers never collide.
• Time-sortable: the first 4 bytes encode creation time, so sorting by _id is close to sorting by "createdAt".
• Custom IDs allowed: you may set your own _id (e.g. an email or SKU) when you already have a natural key.

const { ObjectId } = require('mongodb');

// Generate a new ObjectId
const newId = new ObjectId();
console.log(newId.toString());       // "507f191e810c19729de860ea"

// Extract the creation timestamp
console.log(newId.getTimestamp());   // 2026-01-01T12:34:56.000Z

// Re-create an ObjectId from a stored string (e.g. from a URL param)
const existingId = new ObjectId("507f191e810c19729de860ea");

Embedding vs. Referencing

This is the single most important schema-design decision in MongoDB. When two pieces of data are related, you can either embed one inside the other, or store them separately and reference by _id.

Embedding: store related data together

// A user with their addresses embedded — one read gets it all
{
  "_id": ObjectId("..."),
  "username": "johndoe",
  "addresses": [
    { "type": "home", "city": "New York", "zipCode": "10001" },
    { "type": "work", "city": "New York", "zipCode": "10002" }
  ]
}

Referencing: store related data separately

// The user only stores IDs; addresses live in their own collection
{
  "_id": ObjectId("u1"),
  "username": "johndoe",
  "addressIds": [ ObjectId("a1"), ObjectId("a2") ]
}

// addresses collection
{ "_id": ObjectId("a1"), "userId": ObjectId("u1"), "type": "home", "city": "New York" }
{ "_id": ObjectId("a2"), "userId": ObjectId("u1"), "type": "work", "city": "New York" }

⚠️ The unbounded-array trap. Embedding comments inside a blog post feels natural — until a viral post gets 50,000 comments and blows past the 16 MB document limit. When a "many" side can grow without a clear ceiling, reference it instead.

Relationship Patterns

Most schemas are built from a handful of recurring patterns. Here is how each maps onto documents.

One-to-one → embed

{
  "_id": ObjectId("..."),
  "username": "johndoe",
  "profile": { "bio": "Software developer", "avatarUrl": "/img/jd.png" }
}

One-to-few → embed an array

{
  "_id": ObjectId("..."),
  "name": "ACME Inc.",
  "contacts": [
    { "name": "John Doe",  "role": "CEO", "email": "john@acme.com" },
    { "name": "Jane Smith", "role": "CFO", "email": "jane@acme.com" }
  ]
}

One-to-many → reference (child points to parent)

// authors collection
{ "_id": ObjectId("author123"), "name": "Stephen King" }

// books collection — each book references its author
{ "_id": ObjectId("book1"), "title": "The Shining", "authorId": ObjectId("author123") }
{ "_id": ObjectId("book2"), "title": "It",          "authorId": ObjectId("author123") }

Many-to-many → reference from one (or both) sides

// students collection
{ "_id": ObjectId("s1"), "name": "Alice", "courseIds": [ ObjectId("c1"), ObjectId("c2") ] }

// courses collection
{ "_id": ObjectId("c1"), "name": "Database Design" }
{ "_id": ObjectId("c2"), "name": "Web Security" }

Hands-on Exercise

// users
{ "_id": ObjectId("u1"), "name": "Ray", "email": "ray@example.com",
  "profile": { "bio": "Full stack learner." } }

// posts  (author referenced, tags embedded, comments referenced)
{ "_id": ObjectId("p1"), "title": "Hello Mongo",
  "body": "My first post...", "authorId": ObjectId("u1"),
  "tags": ["mongodb", "nosql"], "createdAt": ISODate("2026-01-01") }

// comments  (each points back to its post and author)
{ "_id": ObjectId("cm1"), "postId": ObjectId("p1"),
  "authorId": ObjectId("u1"), "text": "Great start!",
  "createdAt": ISODate("2026-01-02") }

Best Practices

Summary & Quiz

📚 Further Reading

• MongoDB Manual — Documents
• MongoDB Manual — Data Modeling
• MongoDB Manual — BSON Types

🚀 What's Next?

Now that you can model documents, the next lesson puts them to work: CRUD Operations in MongoDB — inserting, querying, updating, and deleting documents with the Node.js driver.