When do you choose 'Embedding' (De-normalization) over 'Referencing' (Normalization)?

Referencing (or linking) stores related data in separate collections and includes references (like ObjectIds) in the parent document. This is appropriate for one-to-many or many-to-many relationships. For example, an author can have hundreds of books, or a product can be part of many orders. When the related data is frequently accessed on its own, referencing is better. If you need to query all books independently of their authors, storing them in a separate books collection with an authorId reference is the right choice . Referencing also helps with write scalability—if thousands of comments are being added to a post, updating a separate comments collection is more efficient than continually growing and potentially exceeding the 16MB document size limit.

MongoDB's official documentation suggests starting with embedding by default—it's usually the right choice for many use cases . Only move to referencing when you encounter a specific limitation: unbounded growth, excessive data duplication requiring consistency, or when you need to query the related data independently. This 'embed-first' approach often leads to simpler, more performant applications that fit naturally with MongoDB's document model.

Sometimes the best solution is a hybrid approach. You might embed frequently accessed summary data while referencing full details. For example, an orders collection could embed a snapshot of product details at the time of purchase (price, name) while keeping the full product catalog separate. This gives you fast reads for order history without worrying about product price changes affecting past orders. This is a form of denormalization that balances read performance with write complexity.