LearnAI ToolsCareerPractice BuildsPlayContact
Lesson 1918 min read

Schema Design Fundamentals

Learn the core principle that should drive every MongoDB schema decision: design around your application's access patterns.

Flexible Doesn't Mean No Design

MongoDB's flexible schema is a tool, not a substitute for thinking carefully about data modeling. In fact, because MongoDB doesn't enforce relationships and joins the way a relational database does, good schema design arguably matters even more — a poorly modeled MongoDB app can perform far worse than a poorly modeled SQL one.

Design for How You Read, Not Just How You Write

Relational database design traditionally starts from normalization — minimizing duplicate data, regardless of how it's queried. MongoDB schema design instead starts from your application's actual access patterns: what data is read together, how often, and how it changes — then shapes documents around those patterns, even if that means some duplication.

The Central Question

For every entity in your app, ask: "What data do I need at the same time as this?" If the answer is consistently "this other thing," that's a strong signal to embed them together in one document.

A Worked Example

Consider a blog. A post page always needs its comments displayed alongside it — they're read together, every time. Comments are also rarely read independently of their post. This access pattern strongly suggests embedding comments directly inside their post document (covered in depth in the next lesson).

{
  "_id": "1",
  "title": "Getting Started with MongoDB",
  "body": "...",
  "comments": [
    { "author": "Grace", "body": "Great post!" },
    { "author": "Alan", "body": "Very helpful." }
  ]
}

Compare this to a user's orders, which are typically browsed independently of the user's profile, can grow unboundedly over time, and are queried in their own right ("show me all orders over $100"). This pattern instead favors keeping orders in their own separate collection, referencing the user by id — the subject of the following lessons.

Common Beginner Mistakes

Applying relational normalization habits by default

Automatically splitting every relationship into a separate collection (out of SQL habit) often creates unnecessary application-level joins that MongoDB isn't optimized for.

Designing schema before knowing the access patterns

Schema decisions made purely from the shape of the data, without considering how it will actually be queried, frequently need painful rework later — always start from "how will this be read?"

FAQs

No — the right schema depends entirely on how your specific application reads and writes that data; the same entities might be modeled differently for two different apps with different access patterns.

Yes, though it requires a migration strategy (often writing application code that handles both old and new document shapes during a transition) — designing thoughtfully upfront reduces how often this is needed.

Summary

Good MongoDB schema design starts from your application's access patterns, not from normalized theory — data read together is often best stored together. Next, you'll go deep on the central decision this creates: embedding versus referencing.

Next Lesson →

Embedding vs Referencing