Atlas Search Deployment Options
On this page
You can structure your Atlas cluster with different deployment types, cloud providers, and cluster tiers to meet the needs of a pre-production or production environment. Use these recommendations to select the deployment type, cloud provider and region, and cluster and search tiers for performing vector search.
Environment | Deployment Type | Cluster Tier | Cloud Provider Region | Node Architecture |
|---|---|---|---|---|
Testing Queries | Shared or dedicated cluster Local deployment | M0, M2, M5, or higher tierN/A | All N/A | MongoDB and Search processes run on the same node |
Prototyping Applications | Dedicated cluster, sharded or unsharded | M10, M20, or higher tier | All | MongoDB and Search processes run on the same node |
Production | Dedicated cluster with separate Search Nodes, sharded or
unsharded | M10 or higher cluster tier and S10 or higher search
tier | AWS in some regions or Google Cloud and Azure in all regions | MongoDB and Search processes run on different nodes |
To learn more about these deployment models, review the following sections:
Testing and Prototyping Environments
For testing your search queries and prototyping your application, we recommend the following configuration. This configuration is best suited for the following use-cases:
Less than 2M total documents to index.
Less than 10GB of indexed data.
Less than 10,000 queries in a 7-day period.
If your usage exceeds the listed values, migrate to separate search nodes.
Deployment Type
For testing Atlas Search queries, you can deploy a shared or dedicated cluster or a local Atlas deployments.
Cluster Tiers
Shared clusters include the M0, M2, and M5 tiers. These
low-cost cluster types are available for testing your Atlas Search queries.
However, you might experience resource contention and query latency on
shared clusters. If you begin your project with a shared
cluster, we recommend upgrading to a higher tier when your
application is ready for production.
Dedicated clusters include M10 and higher tiers. The M10 and
M20 tiers are suitable for prototyping your application. You can
upgrade to higher tiers to handle large datasets or deploy
dedicated Search Nodes for workload
isolation when your application is ready for production.
Cloud Provider and Region
All the cluster tiers are available in all the supported cloud provider regions. The cloud provider and region that you choose affects the configuration options available for the cluster tiers and the cost of running the cluster.
If you prefer to test Atlas Search queries locally, you can use the Atlas CLI to deploy a single-node replica set hosted on your local computer. To learn more, see Create a Local Atlas Deployment.
When your application is ready for production, migrate your local Atlas deployment to a production environment by using Live Migration. Local deployments are limited by the CPU, memory, and storage resources of your local machine.
Node Architecture
In this deployment model, the search mongot process runs alongside
mongod on each node in the Atlas cluster. The mongod
process routes queries to the mongot on the same node and they share
the same resources.
By default, Atlas enables the search mongot process on the same
node that runs the mongod process when you create your first
Atlas Search index. The mongot process performs the actions
described in About the mongot Process.
You can define stored source
fields in your Atlas Search index so that the mongot process can store the
specified fields on mongot. You can then use the
returnStoredSource Option in
your Atlas Search query to retrieve the stored fields for matching documents
directly from mongot instead of doing a full document lookup on the
database.
Benefits
When you enable Atlas Search, you can easily build search on top of your data
with an integrated, fully managed search engine that automatically
syncs to your database. Atlas Search provides a rich query language that uses
Atlas Search aggregation pipeline stages like $search and
$searchMeta for full-text search and
$vectorSearch for semantic search in conjunction with
other MongoDB aggregation pipeline stages, and score-based results
ranking.
Deploying both the processes on the same node might be more cost-efficient, depending on the resources provisioned for your cluster, than running the search process on a separate, dedicated node.
Limitations
You might experience resource contention between the database mongod
and the search mongot processes. This could negatively impact the
performance of your index and latency of your queries. We recommend this
deployment model for only testing and prototyping environments. For
production-ready applications and associated search workloads, we
recommend migrating to dedicated Search Nodes.
Cost
There are no additional fees or charges when you enable Atlas Search on your Atlas cluster. However, you might observe an increase in resource utilization on the cluster depending on factors such as the size of the indexed collections or index definitions.
Considerations
Since both the mongod and mongot processes run on the same node,
mongot might become unavailable under certain circumstances.
The following table describes potential causes:
Cause | Description |
|---|---|
Cluster Tier Scaling - Network Storage | When you scale a cluster up or down,
Atlas provisions a new instance. Once the instance
is ready, Atlas attaches network storage and starts
both If |
Cluster Tier Scaling - Local SSD | When you scale an Atlas cluster using local SSD,
you can't retain storage and reattach it to the new nodes.
Therefore, Atlas performs an initial sync
to rebuild the search indexes. Search queries fail until the
initial sync is complete. |
Lucene Downgrade | In rare cases where you require downgrading
Lucene, you might not be able
to read newer Lucene index formats. |
Storage Adjustment | You can retain network storage attached to
Atlas cluster nodes. This allows you to expand or contract
the volume capacity with no impact to However, retaining network storage might not be possible in certain regions, when your cluster is using local NVMe disks, or under other rare circumstances. In these cases, Atlas performs an initial sync and search queries fail until the initial sync is complete. |
mongot Version Update | During a mongot version update, Atlas stops the
old version of mongot and starts the new version.
During this brief period, search queries fail until
the new mongot is up. |
New mongod Node | When you add a new node to your cluster, Atlas performs
an initial sync to create the search indexes. Search queries
that use the new mongod node
fail until the initial sync is complete. |
Instance Reboot or Replacement |
|
Production Environment
For your production-ready application, we recommend the following cluster configuration. This configuration in well-suited for the following use-cases:
Greater than 2M total documents to index.
Greater than 10GB of indexed data.
Greater than 10,000 queries in a 7-day period.
Deployment Type
For production-ready applications, you need a dedicated cluster.
Cluster Tiers
Dedicated clusters include M10 and higher tiers. The M10 and
M20 tiers are suitable for development and for production
environments. However, the higher tiers can handle large datasets and
production workloads. We recommend that you also deploy dedicated
Search Nodes for your search workload. This
allows you to scale your search deployment independently and
appropriately.
Cloud Provider and Region
Search Nodes are available in all the regions for Google Cloud and Azure, but only available in a subset of AWS regions. You must select a cloud provider and region where Search Nodes are available for your deployment.
All cluster tiers are available in supported cloud provider regions. The cloud provider and region that you choose affects the configuration options and search tiers available for the cluster and the cost of running the cluster.
Node Architecture
In this deployment model, the mongot process runs on Search Nodes,
which are separate from the cluster nodes on which the mongod
process runs. Atlas deploys Search Nodes with each cluster or
with each shard on the cluster.
For example, if you deploy two Search Nodes for a cluster with three shards, Atlas deploys six Search Nodes, two per shard. You can also configure the number of Search Nodes and the amount of resources provisioned for each search node.
When you deploy separate Search Nodes, Atlas automatically assigns a
mongod for each mongot for indexing. The mongot communicates
with the mongod to listen for and sync index changes for the indexes
that it stores. Atlas Search indexes and processes your queries
similar to when both the mongod and mongot processes run on
the same node. To learn more, see Create and Manage Atlas Search Indexes and Create and Run Atlas Search Queries. To
learn more about deploying Search Nodes separately, see
Search Nodes for Workload Isolation.
When you migrate to Search Nodes, Atlas deploys the Search Nodes, but doesn't serve queries on the nodes until it successfully builds all the indexes on the cluster on the Search Nodes. While Atlas builds the indexes on the new nodes, it continues to serve queries using the indexes on the cluster nodes. Atlas starts serving queries from the Search Nodes only after it successfully builds the indexes on the Search Nodes and removes the indexes on the cluster nodes.
If you delete all the Search Nodes on your cluster, there will be an
interruption in processing your search query results. To learn more, see
Modify a Cluster. If you delete
your Atlas cluster, Atlas pauses and then deletes all
associated Atlas Search deployments (mongot processes).
You can define stored source
fields in your Atlas Search index so that the mongot process can store the
specified fields on mongot. You can then use the
returnStoredSource Option in
your Atlas Search query to retrieve the stored fields for matching documents
directly from mongot instead of doing a full document lookup on the
database.
Benefits
Deploying separate Search Nodes provides the following benefits:
- High Availability
- When you deploy separate Search Nodes, Atlas enforces a minimum of two Search Nodes to ensure your workload remains operational, with minimal downtime, in the event of a failure or disruption.
- Scalability
When you deploy separate Search Nodes, you can do the following:
Scale the storage and compute independent of MongoDB cluster.
Scale query load independent of MongoDB.
You can scale Search Nodes both horizontally and vertically.
You can increase or reduce the number of Search Nodes and horizontally scale your cluster. You can provision between a minimum of 2 to a maximum of 32 Search Nodes, both inclusive. Atlas Search distributes your queries for execution on the Search Nodes by cycling through the list of available Search Nodes, which allows it to balance the query load across all provisioned nodes.
You can select different search tiers for your Search Nodes. The different search tiers enable you to select the CPU, RAM, storage configurations most appropriate for your full-text and vector workload.
- Performance
When you deploy separate Search Nodes, you improve the performance and resource utilization for both the
mongodandmongotprocesses and eliminate resource contention between the two processes.Dedicated Search Nodes support concurrent segment search, which allows Atlas Search to search multiple index segments at the same time and improve query response time in some cases. To learn more, see Parallelize Query Execution Across Segments.
Size and Scale Your Cluster
To determine the amount of memory that you will need on the Search Nodes, use the following Atlas metrics:
Size of the Search Index
Total RAM on the Search Node
For example, consider the following:
Size of the Search Index = 10GB
Total RAM on the Search Node = 4GB
Out of the 4GB of RAM, suppose that 1GB is used by other processes and only 3GB is available for the index data. Therefore, the remaining 7GB of the index data (10GB - 3GB = 7GB) is paged in, as needed, from the disk. Frequent paging from disk (7GB) causes increased page faults, disk I/O, and CPU IOWait, resulting in performance degradation.
A higher search tier with more RAM (8GB or more) allows for most of the data for the search index to be served from the memory, minimizing disk reads and page faults, thereby improving performance.
Note
The local SSDs used for Search Nodes require a 20% storage overhead to support index operations.
Search Nodes Cost
MongoDB supports separate Search Nodes on dedicated (M10 or higher)
clusters. Search Nodes are deployed on compute-intensive NVMe
instances. You must deploy a minimum of two nodes. You will be billed
daily for hourly resource usage per node. To learn more, see
Search Node Costs.
Migrate to Dedicated Search Nodes
With dedicated Search Nodes, you can both size and scale your search deployment separately from your cluster. It also eliminates any resource contention that you might experience on a cluster that runs both the database and search processes on the same node.
To migrate to dedicated Search Nodes, make the following changes to your deployment:
If your deployment is currently using a shared tier, upgrade your cluster to a higher tier. Dedicated Search Nodes are supported only for
M10and higher cluster tiers. To learn more about migrating to a different cluster tier, see Modify the Cluster Tier.Dedicated Search Nodes are available on a subset of the AWS regions and in all supported Google Cloud and Azure regions. Make sure to deploy your cluster in regions where Search Nodes are also available. If your existing cluster is in regions where Search Nodes are not available, migrate your cluster to regions where Search Nodes are available. To learn more, see Cloud Provider Regions.
Enable Search Nodes for workload isolation and configure Search Nodes. To learn more, see Add Search Nodes.
When you deploy separate Search Nodes, Atlas Search continues to serve queries using the indexes on the Atlas cluster while Atlas builds the indexes on the Search Nodes. Atlas routes queries to the Search Nodes only after it completes the following:
Successfully builds all the indexes on the Search Nodes.
Removes the Search Indexes from the cluster nodes.