MongoDB Search - Full-Text and Vector Search | ApsaraDB for MongoDB - ApsaraDB for MongoDB

Full-text search and vector retrieval in MongoDB typically require a separate search engine such as Elasticsearch, which adds architectural complexity and data synchronization overhead.

MongoDB Search embeds dedicated search nodes (mongot) in your instance, providing built-in full-text and vector search that you query with MQL—no external search system required.

Billing (free trial)

MongoDB Search is in invitational preview. Submit a ticket to apply for access. During the preview, mongot search nodes are free. You only pay for your primary MongoDB instance.

Requirements

Dedicated replica set or sharded cluster instances running MongoDB 8.0 or later.
Alibaba Cloud public regions only.
MongoDB 8.3 adds Auto Embedding: mongot automatically generates vectors when you write text, eliminating client-side embedding. MongoDB Search and model service usage example.

How it works

MongoDB Search adds dedicated mongot search nodes to your instance, keeping search workloads isolated from the core database (mongod nodes).

Core architecture: mongot nodes are independent compute resources that handle $search (full-text) and $vectorSearch (vector) queries.
Data synchronization: mongot nodes replicate the oplog from mongod nodes asynchronously via Change Streams, ensuring eventual consistency.
Query routing: When an aggregation contains $search or $vectorSearch, mongos routes the search portion to mongot, merges results with mongod data, and returns a unified result set.

Enable Search service

Purpose

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

Procedure

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.
In the navigation pane on the left, select MongoDB Search.
On the MongoDB Search page, click Activate now.

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

Parameter	Description
Specifications	Select a `mongot` node specification based on your expected QPS and data complexity.
Storage	Disk space for `mongot` search indexes, separate from primary instance storage. Choose a size based on your data volume and index complexity, and leave headroom for growth.

Set search node specifications and storage to at least match your primary instance. You can adjust later based on actual load.

Read and check Service Agreement.
Click Pay.

After creation, view Search node details on the MongoDB Search page. From there you can Upgrade/Downgrade, Restart, or Release the node.

Manage Search nodes

On the MongoDB Search page, you can:

Upgrade or downgrade: Adjust mongot node specifications or storage. Two Search nodes are provisioned by default; the node count cannot be changed.
Restart: Restart your mongot node for troubleshooting or configuration changes. The Search service is 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 Search indexes for full-text or vector search using mongosh or a compatible MongoDB driver.

Prerequisites

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

Example 1: Full-text search on product reviews

Create a full-text Search index on the reviews collection and run keyword-based queries.

Create a Search index with dynamic mapping. dynamic: true indexes all fields automatically—ideal for 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
    }
  }
});

Use the $search aggregation stage to find reviews by keyword. This query matches "good" in the comment field 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

Create a vector search index on the images collection and run similarity searches against stored image vectors.

Create a vector Search index. Specify the vector field, numDimensions, and similarity metric.

// 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"
      }
    ]
  }
);

Use $vectorSearch to find similar images. Provide a queryVector, typically generated by an AI model from the input image.

numCandidates: the candidate set size. Higher values improve recall but increase resource usage and 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. Specify the autoEmbed type when creating a vector index, and mongot automatically calls a specified embedding model such as text-embedding-v4 to generate vectors on document writes. At query time, pass natural-language text directly—the system converts it to a vector before searching.

Advantages over traditional vector search:

No embedding model SDK required in your application.
Vectors are generated and updated automatically on the database side, ensuring consistency.
Unified model proxying through the model service platform, supporting embedding, rerank, and Qwen-series LLMs.

For an end-to-end walkthrough covering model service setup, autoEmbed index creation, semantic search, and model invocation, see MongoDB Search and model service usage example.

Going live

Monitoring and operations

Monitoring metrics: mongot nodes do not yet have dedicated metrics. Monitor CPU, memory, I/O, and network on your primary instance to gauge search workload impact.
Log management: mongot nodes do not support operational, slow-query, or audit logs. Use explain() on $search or $vectorSearch stages to identify performance bottlenecks.
Index management: Run db.collection.getSearchIndexes() to view Search indexes and their status.

High availability and failover

Search nodes use a two-node configuration by default. If one node fails, the system automatically fails over to the remaining healthy node. Implement retry logic in your application.

Backup, restore, and data migration

Backup and restore: Instances restored from backups do not include search indexes. Re-enable Search and rebuild indexes on the restored instance.
Data migration: Data Transmission Service (DTS) and similar tools do not synchronize search indexes. Recreate indexes on the target instance after migration.

FAQ

Q: How long after writing data can I search it?
A: Data synchronization is asynchronous. Data typically becomes searchable within seconds, depending on write volume, document size, and network conditions.
Q: When is an index rebuild triggered? Does upgrading or downgrading trigger a rebuild?
A: Changing an index definition triggers an automatic background rebuild. The old index remains queryable until the new one completes. Node upgrades or downgrades do not trigger index rebuilds.