MongoDB Relationships – Embed vs Reference and Visualize in DbSchema

1. Introduction to MongoDB
2. Installation & Database Creation
3. CRUD Operations
4. Embedded Documents and Arrays
5. Validation Rules - Enforcing Structure in MongoDB
6. Visualize MongoDB Relationships (Embedded vs Referenced) (You are here).
7. What Is an Index in MongoDB?
8. Aggregation Pipeline Explained

Referencing vs embedding: the key difference

Embedding stores related data inside one document for access in one read; referencing stores an id and needs a second lookup, with no foreign-key enforcement either way.

Referenced Relationships

Referenced relationships work a lot like foreign keys in traditional SQL databases. One document stores an _id, and another document refers to it using a field like user_id or movie_id.

Let’s say you have three collections: users, reviews, and movies.

// users
{
  "_id": ObjectId("64fabcde1234567890abc001"),
  "name": "Bob Johnson",
  "phone": "0723-731-652"
}

// movies
{
  "_id": ObjectId("64fabcde1234567890abc002"),
  "title": "Inception",
  "genre": "Sci-Fi",
  "release_date": "2010-07-16"
}

// reviews
{
  "_id": ObjectId("64fabcde1234567890abc003"),
  "user_id": ObjectId("64fabcde1234567890abc001"),
  "movie_id": ObjectId("64fabcde1234567890abc002"),
  "rating": 4,
  "comment": "Great movie!"
}

In this case, the user_id in the reviews collection points to the _id in the users collection, and the movie_id points to the _id in the movies collection. These relationships are not enforced by MongoDB like foreign keys in SQL, but you can use $lookup in aggregation queries to join the data when needed - for example, to show the user who wrote a review and the movie it refers to.

Embedded Relationships

Another way to model relationships in MongoDB is by embedding documents directly inside other documents. This works well when the related data is tightly coupled and usually accessed together.

Instead of storing users, movies, and reviews in separate collections, we can embed the review (and even some user details) inside the movie document.

// movies
{
  "_id": ObjectId("..."),
  "title": "Inception",
  "genre": "Sci-Fi",
  "release_date": "2010-07-16",
  "reviews": [
    {
      "user_name": "Bob Johnson",
      "phone": "0723-731-652",
      "subscription_plan": "Standard",
      "rating": 4,
      "comment": "Great movie, but hard to follow."
    }
  ]
}

In this case:

• The movie and its reviews are stored together in a single document.
• Each review includes user information like name, phone number, and subscription plan.

This model is great when:

• You typically read the movie and its reviews together.
• You don’t need to access or update users separately.
• The embedded data won’t grow too large over time.

However, if a user leaves multiple reviews for different movies, or if user details change often, embedding can lead to duplication and make updates harder to manage. In those cases, referencing is the better choice.

This decision is one of the most important MongoDB design trade-offs. If you are moving from SQL, think of embedding as denormalization and referencing as a softer equivalent of foreign-key-based modeling.

Common MongoDB relationship patterns

Top-ranking relationship guides usually cover more than one-to-many examples, because users want help modeling real schemas:

One-to-one

// user document with embedded profile
{
  "_id": 1,
  "name": "Alice",
  "profile": { "age": 28, "city": "London" }
}

One-to-many

// user document with embedded array of addresses
{
  "_id": 1,
  "name": "Alice",
  "addresses": [
    { "type": "home", "city": "London" },
    { "type": "work", "city": "Manchester" }
  ]
}

Many-to-many

// books and authors using references
// Book
{
  "_id": 101,
  "title": "MongoDB Basics",
  "author_ids": [1, 2]
}
// Author
{
  "_id": 1,
  "name": "Alice"
}

When relationships get complex, $lookup becomes more important. For practical join examples, read MongoDB $lookup and MongoDB aggregation pipelines.

Why visualization matters

Collections and documents can stay understandable for a while in code alone, but larger MongoDB projects usually benefit from diagrams:

• new teammates can understand the schema faster
• virtual relationships expose hidden dependencies between collections
• validation rules and indexes become easier to review together with the data model
• teams can document decisions about when they embedded data and when they referenced it

The Challenge: MongoDB Doesn't Enforce Relationships

Because MongoDB doesn’t enforce relationships between collections, there’s nothing built-in to guarantee data consistency across them.

For example:

• A user_id in a notifications collection might not actually exist in the users collection.
• There are no automatic checks, constraints, or warnings if data goes out of sync.
• Joining related data requires manual $lookup queries - and those can get complex, especially as your data grows.

This flexibility is part of what makes MongoDB powerful - but without structure, it can also become a hidden risk. You lose some of the clarity and safety that comes from defined relationships in relational databases.

Visual Relationships with DbSchema

That’s where DbSchema helps.

DbSchema builds that picture by sampling documents in each collection and inferring field names, BSON types, nested objects and arrays from what it finds. The diagram is an approximation of what the documents currently contain, not a schema MongoDB itself enforces - collections reverse-engineered this way are flagged “Inferred (no validation)”, and structure is enforced only where a collection validator has been written and applied.

Even though MongoDB doesn't have built-in foreign keys, DbSchema lets you define virtual relationships between collections. You can drag a line from users._id to notifications.user_id, for example - and visually connect the dots.

These virtual relationships are:

• Not stored in the database
• Used only inside DbSchema
• Incredibly useful for understanding structure and exploring your data

Read how you can create virtual relationships in MongoDB in this article.

You can even use them in the Data Explorer to follow connections across collections - without writing any joins by hand.

Read how you can explore related collections using virtual relationships in DbSchema in this article.

It’s a great way to bring back structure, clarity, and teamwork - without giving up MongoDB’s flexibility.

For a broader product workflow, combine this with the diagram documentation, the MongoDB tool page, and the guide on MongoDB schema design.

Download DbSchema, connect it to your own MongoDB database and reverse-engineer the collections you are modelling, then draw the virtual relations your documents imply. The free Community Edition covers connecting, reverse-engineering and interactive diagrams; relational data browse - following those relations across collections in the Data Explorer - is part of Pro.

FAQ

Should I embed or reference in MongoDB?

Embed when the related data is small, tightly coupled, and usually read together. Reference when the data changes independently, is shared by multiple collections, or can grow large.

Can MongoDB support many-to-many relationships?

Yes. MongoDB can model many-to-many relationships with arrays of references, bridge-style collections, or a combination of references and $lookup.

Does MongoDB enforce foreign keys?

No. MongoDB does not enforce foreign keys the way relational databases do, which is why visual modeling and validation rules are helpful.

How do I visualize MongoDB relationships?

You can define and inspect virtual relationships in DbSchema, which gives you diagram-based visibility without changing the actual database.