MongoDB Relationships - Embedded vs Referenced | Tutorial 2025

Mongodb • 08-May-2025

by Roxana Haidiner

Visualize MongoDB Relationships

MongoDB is flexible, fast, and great for modern applications. But that flexibility comes with a challenge: how do you organize and connect your data without the strict structure of relational databases?

In this article, we’ll break down how relationships work in MongoDB using two main approaches: referencing and embedding. Then we’ll look at how you can bring structure and visibility to those connections using virtual relationships in DbSchema - a visual design tool for MongoDB.

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.

Example

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

// users
{
  "_id": ObjectId("64fabcde1234567890abc001"),
  "name": "Bob Johnson",
  "email": "[email protected]"
}

// 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.

Example

// movies
{
  "_id": ObjectId("..."),
  "title": "Inception",
  "genre": "Sci-Fi",
  "release_date": "2010-07-16",
  "reviews": [
    {
      "user_name": "Bob Johnson",
      "email": "[email protected]",
      "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, email, 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.

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.

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.

Virtual Relationship for MongoDB in DbSchema