Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /

How Automated Embedding Works

You can configure MongoDB Vector Search to automatically generate and manage vector embeddings for the text data in your cluster. You can create a one-click AI semantic search index in your cluster and use Voyage AI embedding models, simplifying indexing, updating, and querying with vectors.

When you enable Automated Embedding, MongoDB Vector Search automatically generates embeddings using the specified embedding model at index-time for the specified text field in your collection and at query-time for your text string in your query against the field indexed for automated embeddings.

When you create a MongoDB Vector Search index for Automated Embedding, MongoDB performs an initial synchronization to generate embeddings for all existing documents in your collection:

  1. Scans documents.

    MongoDB Vector Search scans all documents in the collection that contain the indexed text field.

  2. Generates embeddings.

    For each document, MongoDB Vector Search sends the text from the indexed field to the Voyage AI embedding model to generate vector embeddings.

  3. Stores embeddings.

    MongoDB Vector Search stores the generated embeddings in a separate internal system collection (__mdb_internal_search) on the same cluster to keep the embeddings isolated from your application data while maintaining data locality.

  4. Builds index.

    After embeddings are generated, MongoDB Vector Search builds the index using the generated embeddings to enable vector search.

During the initial sync, MongoDB processes documents in batches and uses a special Flex inference processing tier to optimize throughput.

Note

The initial sync duration depends on the number of documents, the length of text in the indexed field, and the available rate limit quota. It might take several hours to complete the initial sync for large collections.

After the initial sync, MongoDB Vector Search keeps embeddings automatically synchronized with your data as it changes.

When you insert a new document with the indexed text field, MongoDB Vector Search automatically:

  1. Detects the new document through change streams.

  2. Generates embeddings for the text field using the configured model.

  3. Stores the embeddings in the system collection.

  4. Updates the MongoDB Vector Search index to include the new embeddings.

When you update a document and the indexed text field changes, MongoDB Vector Search automatically:

  1. Detects the field change through change streams.

  2. Generates new embeddings for the updated text.

  3. Replaces the old embeddings in the system collection.

  4. Updates the MongoDB Vector Search index with the new embeddings.

Note

MongoDB Vector Search doesn't trigger embedding regeneration for updates to fields that aren't indexed for Automated Embedding.

When you delete a document, MongoDB Vector Search automatically removes the corresponding embeddings from the system collection and updates the index.

Automated Embedding uses Voyage AI's embedding models, which are hosted and managed by MongoDB in a multi-tenant environment:

  • Hosted Service: All embedding models are hosted and maintained by MongoDB. The model inference platform runs on MongoDB's infrastructure in Google Cloud cloud in a US region. You don't need to deploy, configure, or manage any model infrastructure.

  • API-Based Access: For self-managed deployments that are configured to use Voyage AI API key, MongoDB sends text to Voyage AI's API endpoints to generate embeddings. The embeddings are returned to MongoDB and stored in your cluster.

  • Multi-Tenant Architecture: The embedding service is shared across multiple users. This multi-tenant model provides:

    • Cost efficiency through shared infrastructure

    • Automatic model updates and improvements

    • High availability and scalability

  • Text sent to Automated Embedding service is used only to generate embeddings and is not stored or used for model training.

  • Embeddings are returned to your MongoDB cluster and stored within your own database.

  • All communication with the Automated Embedding service occurs over encrypted connections.

The embedding service is multi-tenant. Therefore, MongoDB enforces rate limits to ensure fair usage across all customers. To learn more about rate limits and how they affect Automated Embedding operations, see Rate Limits.

When you run a vector search query using Automated Embedding, MongoDB automatically handles embedding generation for your query text:

  1. Query Text Submission: You provide a text string in the query field of the $vectorSearch stage instead of a pre-generated vector.

  2. Embedding Generation: MongoDB sends your query text to the Automated Embedding service to generate embeddings using the same model specified in the index (or a compatible model if you override it with the model option).

  3. Vector Search: The generated query embeddings are used to search the indexed embeddings using the configured similarity function (cosine, dotProduct, or euclidean).

  4. Results Returned: MongoDB returns documents ranked by similarity to your query.

Each query that uses Automated Embedding counts toward your Automated Embedding rate limits because it requires an API call to generate embeddings. To learn more about managing query throughput and costs, see Rate Limits.

  • Large collections might take significant time to complete initial sync if you hit rate limits.

  • MongoDB automatically retries failed embedding requests and implements exponential backoff.

  • You can monitor sync progress through Atlas Search monitoring.

  • Document updates are processed as they occur, subject to rate limits.

  • If updates exceed rate limits, they are queued and processed when capacity becomes available.

  • Your application continues to function normally; only embedding generation might be delayed.

  • Query rate limits affect how many concurrent searches you can perform.

  • If you exceed query rate limits, queries return an error indicating the rate limit has been exceeded.

  • Consider caching frequently used query results or upgrading to a paid tier for higher throughput.

Automated Embedding uses a separate reserve database to store vector embeddings. You can find the generated embeddings collection for an index and retrieve the embeddings from the generated embeddings collection.

Embeddings Storage

MongoDB stores the generated embeddings asynchronously and persists them in an internal generated embeddings collection. This generated embeddings collection exists in a dedicated internal database named __mdb_internal_search on the same cluster. Every auto-embedding index in the cluster has exactly one corresponding generated embeddings collection inside this database. To learn more, see Generated Embeddings Collection.

Warning

The __mdb_internal_search database is a reserved internal namespace created and managed by MongoDB. Don't manipulate this database or its collections. If you modify this reserved namespace, it could result in index failures and inconsistent search results.

Structure of the Generated Embeddings Collection

The generated embeddings collection contains one document per source-collection document. Each generated embeddings collection document has the same _id as the source, copies of the source's filter fields, and the generated embedding vector for each Automated Embedding field.

You can see the following fields:

Field
Type
Description

_id

ObjectId

Same _id as the source document.

<filter-field>

Any

Copy of the filter field from the source document.

_autoEmbed

Object

Contains the embedding vector for each Automated Embedding field.

_autoEmbed.
<fieldPath>

Array of float or quantized vector

Contains the generated embedding vector for the Automated Embedding field.

Warning

The __mdb_internal_search database is a reserved internal namespace created and managed by MongoDB. Don't manipulate this database or its collections. If you modify this reserved namespace, it could result in index failures and inconsistent search results.

You can check the storage size of generated embeddings collections to understand disk and index space consumption from generated embeddings. This is useful for capacity planning, debugging unexpected growth, and validating cleanup after dropping or redefining an index.

Important

Before checking storage size, find your generated embeddings collection name. To learn more, see Find the Generated Embeddings Collection.

The following sections provide guidance for troubleshooting common issues with Automated Embedding.

No generated embeddings collection matching the index ID
Your index might still be in :guialbel`Building` or Pending state. The generated embeddings collection is created lazily on first write. Check status using the $listSearchIndexes.
Document missing for a source _id
The embedding for that the specified document has not yet been generated, or the document was filtered out by the index's filter expression.
More than one collection matches the index ID
The auto-embed field configuration has been updated. Although a new generated embeddings collection has been created, the old one might linger briefly until cleanup.

Back

Manage Billing