Search the Way You Model: Nested Embeddings in MongoDB Atlas

Nested Embedding support for MongoDB Vector Search is now available in public preview on Atlas.

Since integrating vector search directly into MongoDB Atlas in 2023, we've continued expanding the platform with capabilities like Lexical Prefilters, Flat Indexes, and Automated Embedding. Nested embedding support continues this momentum, allowing developers to add semantic search to existing hierarchical collections without restructuring their data or query patterns.

The nested document search challenge

MongoDB's document model excels at representing hierarchical, real-world data. A book has chapters. A product has reviews. A knowledge base article has sections. In each case, it's natural to model the data as a parent document with an array of subdocuments—each containing its own text, metadata, and embedding.

Until now, developers who wanted to perform vector search over these nested embeddings had to remodel their data schemas into flat, root-level documents that duplicated metadata to represent relationships. This conflicted with MongoDB's recommended embedded document pattern and introduced several challenges:

• Data model compromise: The commonly recommended embedded document pattern had to be abandoned in favor of the extended reference pattern, purely to accommodate vector search limitations.
• Metadata duplication at scale: Flattening nested documents into root-level collections required copying parent metadata into every child document, increasing storage costs and creating synchronization overhead.
• Reassembly complexity: After performing vector search on flattened documents, developers needed a subsequent $lookup stage on every query, adding latency and pipeline complexity.

Searching your data the way you model it

With nested embedding support, developers can now index vector embeddings stored inside arrays of subdocuments and retrieve parent documents without flattening their data or duplicating metadata.

Key benefits:

• Keep your data model intact: Store and search your data the same way, without splitting nested documents into separate collections or adding foreign key lookups to reassemble results.
• Flexible scoring: Control how child-level similarity scores roll up to the parent document. Use max to surface documents with at least one highly relevant match, or avg to rank by overall alignment across all matching children.
• Precise results, at every level: Filter child embeddings and parent documents independently, so the results reflect both the right context and the right match.

When nested embeddings make sense

Nested embedding support is purpose-built for applications where the natural unit of retrieval is a parent document, not an individual chunk. Consider using it if:

• Your documents contain arrays of subdocuments, each with its own vector embedding (e.g., sections, chunks, reviews, translations).
• You want to retrieve parent documents ranked by how well their best, or average, child embedding matches a query.
• You're building RAG with chunked documents and want to retrieve the full parent document as the source context.
• Your data already uses MongoDB's embedded document pattern, and you don't want to flatten it into separate collections to enable vector search.

One technical consideration: parent documents must stay within MongoDB's 16MB BSON limit after embeddings are included. For most standard embedding models, this isn't a concern, but it's worth accounting for when storing large arrays of high-dimensional subdocuments.

Built into your existing workflow

Nested embedding support is built into MongoDB Atlas and works with the existing $vectorSearch aggregation stage. It preserves the same query API, security model, and driver compatibility you already rely on. Jump in with an example of how to define a nested vector index and query across embedded subdocuments.