MongoDB Search

Implementing complex full-text search or AI-powered vector retrieval in MongoDB often requires introducing and maintaining a separate search engine, such as Elasticsearch. This adds complexity to your system architecture and incurs additional costs for data synchronization and operations.

The MongoDB Search feature integrates dedicated search nodes (mongot) into your MongoDB instance, delivering seamless full-text and vector search capabilities. Use the MongoDB Query Language (MQL) to perform multimodal search tasks without managing an external search system—simplifying development and reducing operational overhead.

Billing details (free trial)

MongoDB Search is currently in invitational preview. Apply for access by filling out a form. During this period, you will not be charged for the mongot search nodes. You only pay for your primary MongoDB instance.

Supported scenarios

• Currently supports only Dedicated replica set instances or Dedicated sharded cluster instances running MongoDB 8.0 or later.

• Currently supports only Alibaba Cloud public regions.

• MongoDB 8.3 supports Auto Embedding: when you write text, mongot automatically generates vectors—no need to precompute embeddings on the client side. For detailed usage examples, see MongoDB Search and model service usage example.

How it works

MongoDB Search isolates search workloads by adding dedicated mongot search nodes to your instance. This architecture ensures that intensive search tasks do not affect the performance of your core database (mongod nodes).

• Core architecture: mongot nodes are independent compute resources dedicated to handling full-text and vector search requests—specifically, $search (full-text search) and $vectorSearch (vector search) queries.

• Data synchronization: mongot nodes asynchronously replicate the oplog from mongod nodes using Change Streams to keep index data synchronized, ensuring eventual consistency.

• Query routing: When you run an aggregation query containing $search or $vectorSearch, mongos routes the search portion to the mongot node. It then merges the search results with regular query results from the mongod node and returns a unified result set.

Enable Search service

Purpose

Enable the Search feature on an existing MongoDB instance to create dedicated mongot search nodes.

Procedure

1. Go to the Replica Set Instances or Sharded Cluster Instances page. In the top navigation bar, select the resource group and region to which the desired instance belongs. Then, find the instance and click the instance ID.

2. In the navigation pane on the left, select MongoDB Search.

3. On the MongoDB Search page, click Activate now.

4. In the Enable Search panel, configure the Search Node Specifications.

   Parameter	Description
   Specifications	Select an appropriate compute specification for your mongot search node based on expected query concurrency (QPS) and data complexity.
   Storage	Allocate disk space for the mongot node to store Search indexes. This space is separate from your primary instance’s storage. Estimate based on source data volume and index complexity, and leave some headroom.

   We recommend that your search node specifications and storage size be at least equal to those of your primary instance. You can change the configuration later based on actual load.

5. Read and check Service Agreement.

6. Click Pay.

After successful creation, view your new Search node details on the MongoDB Search page. You can then perform Upgrade/Downgrade, Restart, or Release operations.

Manage Search nodes

On the MongoDB Search page, you can perform the following actions on your created Search nodes:

• Upgrade or downgrade: Adjust the compute specifications or storage space of your mongot node to match changing business needs. By default, you get two Search nodes. Changing the node count is not supported.

• Restart: Restart your mongot node when troubleshooting or applying certain configurations. The Search service will be briefly unavailable during restart.

• Release: Release your mongot node if you no longer need Search functionality.

  Important

  Releasing permanently deletes all Search indexes. This action cannot be undone.

Create and use Search indexes

Purpose

Create different types of Search indexes to enable full-text or vector search. Perform all operations using MongoDB Shell (mongosh) or a compatible MongoDB driver.

Prerequisites

You have connected to your target MongoDB instance using mongosh or your application.

Example 1: Full-text search on product reviews

This example shows how to create a full-text Search index on the reviews collection and run keyword-based queries.

1. Create a Search index with dynamic mapping. Setting dynamic: true lets MongoDB automatically index all fields in the collection—ideal for rapid prototyping.

   // Create a Search index named 'reviews_full_text_index' on the 'reviews' collection
   db.reviews.createSearchIndex({
     name: "reviews_full_text_index",
     definition: {
       "mappings": {
         "dynamic": true
       }
     }
   });
   

2. Use the $search aggregation stage to find reviews containing a specific keyword. The following query finds reviews where the comment field contains “good” and returns the comment, rating, and product ID.

   db.reviews.aggregate([
     {
       $search: {
         index: "reviews_full_text_index", // Specify the Search index to use
         text: {
           query: "good", // Search keyword
           path: "comment"      // Search in the 'comment' field
         }
       }
     },
     {
       $limit: 5
     },
     {
       $project: {
         _id: 0,
         productId: 1,
         rating: 1,
         comment: 1,
         score: { $meta: "searchScore" } // Return relevance score
       }
     }
   ]);
   

Example 2: Search by image using visual features

This example shows how to create a vector Search index on the images collection—which stores image vector features—and run similarity searches.

1. Create a vector Search index. Specify the vector field path, dimensionality (numDimensions), and similarity metric (similarity).

   // Create a vector index named 'vector_index' on the 'images' collection
   db.images.createSearchIndex(
     "vector_index", 
     "vectorSearch", 
     {
       "fields": [
         {
           "type": "vector",
           "path": "plot_embedding_voyage_3_large",// Field storing vectors
           "numDimensions": 2048,// Vector dimensionality
           "similarity": "dotProduct",// Similarity metric
           "quantization": "scalar"
         }
       ]
     }
   );
   

2. Use the $vectorSearch aggregation stage to find images most similar to a given image. Provide a query vector (queryVector), typically generated by an AI model from the input image.

   numCandidates: candidate set size. This parameter balances performance and recall rate. Increasing it improves recall accuracy but uses more resources and may increase latency.

   // Assume QUERY_EMBEDDING is a 1024-dimensional vector generated by an AI model
   const QUERY_EMBEDDING = [0.12, 0.45, -0.23, ...]; // Example vector—replace with real data
   // Retrieve based on vector similarity
   db.images.aggregate([
     {
       "$vectorSearch": {
         "index": "vector_index",
         "path": "plot_embedding_voyage_3_large",
         "queryVector": QUERY_EMBEDDING,
         "numCandidates": 150,
         "limit": 10,
         "quantization": "scalar"
       }
     },
     {
       "$project": {
         "_id": 0,
         "plot": 1,
         "title": 1,
         "score": { $meta: "vectorSearchScore" }
       }
     }
   ])
   

Auto Embedding (new in 8.3)

MongoDB 8.3 introduces Auto Embedding. When creating a vector index, specify the autoEmbed type. After writing a document, mongot automatically calls a specified embedding model, such as text-embedding-v4, to generate vectors for the target field—no need to precompute embeddings on the client. At query time, pass natural language text directly. The system automatically converts it to a vector before searching.

Compared to traditional vector search, Auto Embedding offers these advantages:

• No need to integrate an embedding model SDK in your application layer—reducing development complexity.

• Vector generation and updates happen automatically on the database side, ensuring data-vector consistency.

• Supports unified proxying of model calls through the model service platform—including popular embedding, rerank, and Qwen-series large language models.

For a complete end-to-end example—including enabling model service, creating an autoEmbed index, semantic search, and model invocation—see MongoDB Search and model service usage example.

Going live

Monitoring and operations

• Monitoring metrics: mongot search nodes do not yet have dedicated monitoring metrics. Monitor CPU, memory, I/O, and network metrics of your primary instance to indirectly assess search workload impact.

• Log management: mongot nodes do not support viewing operational logs, slow query logs, or audit logs. To troubleshoot slow queries, use the explain() method to analyze the execution plan of $search or $vectorSearch stages and identify performance bottlenecks.

• Index management: Use the db.collection.getSearchIndexes() command to view created Search indexes and their status.

High availability and failover

• Search nodes deploy by default in a two-node configuration. If one node fails, the system automatically performs failover and routes traffic to the healthy node. Ensure your application implements retry logic.

Backup and restore, and data synchronization

• Backup and restore: A new instance restored from a backup file does not include the original instance’s Search indexes. Re-enable the Search service on the new instance and rebuild all indexes manually.

• Data migration: When migrating or synchronizing data using tools like Data Transmission Service (DTS), Search indexes are not synchronized. Create indexes manually on the target instance.

FAQ

• Q: How long after writing data can I search it?

  A: Data synchronization is asynchronous. Searches typically become available within seconds. Delay depends on write load, document size, and network conditions.

• Q: When is an index rebuild triggered? Does upgrading or downgrading trigger a rebuild?

  A: When you change an index definition, mongot automatically rebuilds the index in the background. The old index remains available for queries until the new one finishes building. Upgrading or downgrading search nodes is not directly linked to index rebuilds.