Embedding: relazioni uno-a-pochi

Embedding means storing related data directly inside a parent document rather than in a separate collection. Instead of linking two collections with a foreign key, you nest the related data as a sub-document or an array of sub-documents. This is MongoDB's most powerful design tool because it allows a single read to retrieve the parent and all its related data at once.

A one-to-few relationship exists when one parent document has a small, bounded number of child items—typically fewer than a few dozen. Classic examples include a blog post and its comments, a user and their addresses, or an order and its line items. When the child count is predictable and small, embedding is almost always the right choice.

Consider a users collection where each user has one or two delivery addresses. Instead of a separate addresses collection, embed them directly. This means finding a user and their addresses requires one query with zero joins.

When data is embedded, you retrieve the parent document and all its children with a single findOne. There is no need for a $lookup or a second round trip to the database. This makes reads faster and the application code simpler, since the entire object graph arrives in one response.

To update an embedded sub-document, use the positional operator $ or dot notation. For example, changing the zip code of Alice's home address targets the specific array element that matches a filter condition. Embedded updates happen atomically at the document level—no transaction needed.

MongoDB stores documents as contiguous BSON blobs on disk. When you embed related data, the engine reads one block of storage instead of two separate collection scans. This co-location of related data is the core reason embedded documents outperform referencing for read-heavy workloads where the parent and children are almost always accessed together.

In Mongoose, you define sub-document schemas and nest them inside the parent schema. Mongoose treats embedded arrays as sub-document arrays, providing full type validation and lifecycle hooks on each element. The parent model saves the entire tree atomically.

Embedding works best when: (1) the child data is always accessed with the parent; (2) the number of children is small and bounded; (3) the children do not need their own independent lifecycle (e.g., they are never queried or updated in isolation). If all three conditions are true, embedding is almost certainly the optimal choice.

Every MongoDB document has a hard size limit of 16 MB. For one-to-few relationships, this is rarely a concern—a user with ten addresses or an order with twenty line items is well within the limit. However, you should monitor document growth over time to make sure embedding does not push documents toward the ceiling.

Use this quick comparison to guide your choice:

• Embedding: one query, atomic updates, small bounded child count
• Referencing: flexible child count, shared children, independent child queries

For one-to-few relationships, embedding wins on almost every metric. You avoid extra network round trips and keep your schema simple.

A blog post typically has a small, fixed set of tags. Rather than maintaining a separate tags collection with references, embed the tags as an array of strings directly in the post document. Querying posts by tag is efficient with a multikey index on the tags field, and reading a post always returns its tags in the same document.

In this lesson you learned: embedding places related data inside the parent document, one-to-few relationships benefit from embedding because a single read fetches all data, and Mongoose supports sub-document schemas for type-safe embedded arrays. Next up we explore referencing—when to link documents across collections instead of nesting them.