Schema Design

Oct 6, 2026

• MongoDB

  Data Modeling and Schema Design for MongoDB Search Part 1: Practical Considerations

  Data modeling for MongoDB Search requires balancing conceptual, logical, and physical schema decisions against workload demands and system constraints. The $search stage must be the first in an aggregation pipeline, queries a single Search index, and runs against a single collection, with results returned in relevancy order. The underlying Lucene engine supports two mappings for arrays of sub-documents: default document mapping flattens fields into one index object, while embeddedDocuments mapping creates separate Lucene index objects per sub-document. Embedded mapping enables cross-field matching within sub-documents but explodes the index object count and causes heavy reindexing on any update, as the entire block is deleted and re-added. This post establishes the foundational concepts and physical constraints that will inform schema patterns in Part 2.

• MongoDB

  Data Modeling and Schema Design for MongoDB Search Part 2: Use Cases and Patterns

  The post presents best practices for data modeling and schema design in MongoDB Search, covering use cases and patterns such as the Entity Pattern to guide developers in structuring collections for effective search. It emphasizes that searchable items, like movies, cast members, or genres, should be modeled as first-class documents in their own collections rather than as nested structures or ambiguous attributes. The Entity Pattern addresses ‘find anything anywhere’ and as-you-type suggestions by representing all domain entities as documents in a specialized collection with stable identifiers and a type field for filtering. The Attribute Pattern is explicitly discouraged for search because its key-value structure prevents type-sensitive field mapping, making it better to model attributes as straightforward fields. The post details a multi-indexing strategy on the name field that applies left-edge, phonetic, shingled, and language-agnostic analysis to enable flexible matching and relevancy scoring, with optional type-specific metadata nested in sub-documents.