---
title: "Data Modeling and Schema Design for MongoDB Search Part 1: Practical Considerations"
description: "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."
---

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

[MongoDB](https://yomu.fyi/company/mongodb) · Oct 6, 2026

**Type:** Explainer

## Summary

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.

## Context

Part 1 of a series on data modeling and schema design for MongoDB Search. It covers conceptual, logical, and physical data models, how the $search stage fits into the aggregation pipeline, and the trade-offs between document and embeddedDocuments mappings for arrays of sub-documents.

## Approach / What changed

A methodology for schema design in MongoDB Search that involves analyzing use case workloads, understanding physical constraints (single collection/index, $search as first stage in aggregation pipeline), and selecting between document and embeddedDocuments field mappings based on cross-field matching needs and index object scale.

## Takeaways

- The $search stage must be the first stage in an aggregation pipeline and queries a single MongoDB Search index tied to one collection.
- EmbeddedDocuments mapping creates separate Lucene index objects per sub-document; any update reindexes the entire block, causing thrash as the number of embedded elements grows.
- Default document mapping flattens nested fields into a single Lucene index object, preventing cross-field matching within sub-documents but avoiding index object explosion.

## FAQ

### When should I use embeddedDocuments mapping instead of default document mapping?

Use embeddedDocuments when you need to match across multiple fields within the same sub-document, such as finding a parent with a child aged 5 and named Kid2. Default document mapping flattens fields into one index object, preventing such cross-field matching.

### Why does updating a document with many embedded documents cause performance issues?

Each update triggers a delete and re-add of the entire block of Lucene index objects for that document. The more embedded documents, the heavier the reindexing cost, which can significantly impact performance.

### How does the $search stage affect aggregation pipeline performance?

$search must be the first stage and returns all matching documents unless limited. Post-search stages like $group can drastically reduce performance if applied to large result sets. Design for limited results and use searchAfter for pagination.

**Tags:** [Lucene](https://yomu.fyi/topic/lucene), [MongoDB](https://yomu.fyi/topic/mongodb), [MongoDB Atlas](https://yomu.fyi/topic/mongodb-atlas), [Schema Design](https://yomu.fyi/topic/schema-design), [Search](https://yomu.fyi/topic/search)

- Source: [MongoDB](https://www.mongodb.com/company/blog/technical/data-modeling-schema-design-for-search-part-1-practical-considerations)
- Source URL: https://www.mongodb.com/company/blog/technical/data-modeling-schema-design-for-search-part-1-practical-considerations
- Ingested by Yomu: 2026-10-07T15:00:14.725Z

[Read original post](https://www.mongodb.com/company/blog/technical/data-modeling-schema-design-for-search-part-1-practical-considerations)