What is the difference between embed and reference in MongoDB schema design?

Embedding (denormalization): store related data inside the same document as nested objects or arrays. Example: store a user's address embedded in the user document instead of a separate addresses collection. Embedding pros: single query to get all related data (no joins); atomic updates to the whole document; better read performance (single I/O); intuitive document structure. Embedding cons: document size can grow large (MongoDB 16MB limit); if the embedded data is updated frequently, the entire document must be rewritten; if embedded data needs to be accessed independently, it's hard; data duplication if the same data is embedded in multiple documents. When to embed: "one-to-few" relationship (user → addresses, order → order items); data accessed together; child data not needed independently; child data is bounded in size. Referencing (normalization): store only the related document's _id and look it up separately (like a foreign key). Referencing pros: avoids data duplication; documents stay small and focused; referenced data can be accessed independently; works for large or unbounded relationships. Referencing cons: requires additional queries or $lookup for joins; no referential integrity enforcement (MongoDB won't prevent orphan references). When to reference: "one-to-many" (blog → comments — potentially thousands), "many-to-many" (students ↔ courses), when the related data is large, frequently updated, or accessed independently. Hybrid: denormalize frequently-read fields (store author name with each post) but reference the full author document.