> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # MongoDB Search Deployment Options ## Overview The following sections describe deployment options for MongoDB Search on Atlas. You can structure your 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 | Flex or dedicated clusterLocal deployment | Free cluster, Flex, or higher tierN/A | AllN/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 `S20` or higher search tier | AWS (Amazon Web Services) and Azure (Microsoft Azure) in some [regions](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-fts-cloud-provider-regions) or Google Cloud in all regions | MongoDB and Search processes run on different nodes. | | Community Edition | Self-managed deployment. You install and operate `mongod` and `mongot` yourself. | N/A. You provide your own hardware or cloud instances. | N/A. You choose your own infrastructure. | MongoDB and Search processes run on either a single or separate self-managed hosts. | The following sections describe each environment: - [Testing and Prototyping Environments](https://www.mongodb.com/docs/search/deployment/deployment-options.md#std-label-fts-deployment-options-testing) - [Production Environment](https://www.mongodb.com/docs/search/deployment/deployment-options.md#std-label-fts-deployment-options-production) - [MongoDB Community Edition](https://www.mongodb.com/docs/search/deployment/deployment-options.md#std-label-fts-deployment-options-community) ## Testing and Prototyping Environments For testing your search queries and prototyping your application, we recommend the deployment type and node architecture described in the following sections. 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 dedicated search nodes.](https://www.mongodb.com/docs/search/deployment/deployment-options.md#std-label-fts-migrate-to-decoupled) The following sections describe this node architecture in more detail. Deployment Type To test MongoDB Search queries on clusters in the cloud, you can deploy a Flex or dedicated cluster. To test MongoDB Search queries locally, [create a local Atlas deployment](https://www.mongodb.com/docs/atlas/cli/current/atlas-cli-deploy-local/) using the Atlas CLI. This could be a single-node replica set hosted on your local computer. Local deployments are limited by the CPU, memory, and storage resources of your local machine. When your application is ready for production, [migrate](https://www.mongodb.com/docs/atlas/live-migration.md#std-label-c2c-pull-live-migration) your local Atlas deployment to a production environment. Cluster Tiers For testing your MongoDB Search queries, use Free clusters (formerly known as `M0`) and Flex clusters. For prototyping your application, use dedicated `M10`, `M20`, and higher tier clusters or deploy [dedicated Search Nodes](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-configure-search-nodes) for workload isolation. When your application is ready for production and to handle large datasets, scale to higher tiers. Cloud Provider and Region Use any supported cloud provider region. The cloud provider and region that you choose affect the configuration options available for the cluster tiers and the [cost of running the cluster.](https://www.mongodb.com/docs/atlas/billing.md#std-label-atlas-billing) ### Node Architecture For testing and prototyping environments, we recommend a node architecture in which MongoDB processes and MongoDB Search processes run on the same node. In the following diagram of this deployment model, the MongoDB Search `mongot` process runs alongside `mongod` on each node in the Atlas cluster and they share the same resources. ![MongoDB Search architecture](/_includes/images/deployment/fts-architecture-diagram.png) By default, Atlas enables the MongoDB Search `mongot` process on the same node that runs the `mongod` process when you create your first MongoDB Search index. To learn how MongoDB Search processes queries on this architecture, see [Query Processing.](https://www.mongodb.com/docs/search/query/query-ref.md#std-label-about-mongot) You can define [stored source](https://www.mongodb.com/docs/search/indexes/stored-source-definition.md#std-label-fts-stored-source-definition) fields in your MongoDB Search index so that the `mongot` process can store the specified fields on `mongot`. You can then use the [returnStoredSource Option](https://www.mongodb.com/docs/search/query/return-stored-source.md#std-label-fts-return-stored-source-option) in your MongoDB Search query to retrieve the stored fields for matching documents directly from `mongot` instead of doing a full document lookup on the database. **See also:** - [Supported Clients](https://www.mongodb.com/docs/search/indexes/manage-indexes.md#std-label-fts-manage-indexes) - [Queries and Indexes](https://www.mongodb.com/docs/search/about/searching.md#std-label-fts-about-queries) ### Benefits When you enable MongoDB Search, you can easily build search on top of your data with an integrated, fully managed search engine that automatically syncs to your database. MongoDB Search provides a rich query language that uses MongoDB Search aggregation pipeline stages like [`$search`](https://www.mongodb.com/docs/search/query/aggregation-stages/search.md#mongodb-pipeline-pipe.-search) and [`$searchMeta`](https://www.mongodb.com/docs/search/query/aggregation-stages/searchmeta.md#mongodb-pipeline-pipe.-searchMeta) for full-text search and [`$vectorSearch`](https://www.mongodb.com/docs/vector-search/query/aggregation-stages/vector-search-stage.md#mongodb-pipeline-pipe.-vectorSearch) for semantic search in conjunction with other MongoDB aggregation pipeline stages, and score-based results ranking. Depending on the resources provisioned for your cluster, deploying both processes on the same node might be more cost-efficient 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. To support production-ready applications and their search workloads [migrate to dedicated Search Nodes.](https://www.mongodb.com/docs/vector-search/deployment/deployment-options.md#std-label-avs-migrate-to-decoupled) ### Cost There are no additional fees or charges when you enable MongoDB Search on your cluster. However, you might observe an increase in resource utilization on the cluster for large 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 `mongod` and `mongot` on the new nodes. If `mongod` starts before `mongot`, MongoDB Search queries fail until `mongot` is running. | | cluster Tier Scaling - Local SSD (Solid State Disk) | When you scale an Atlas cluster using local SSD (Solid State Disk), you can't retain storage and reattach it to the new nodes. Therefore, Atlas performs an [initial sync](https://www.mongodb.com/docs/search/performance/index-performance.md#std-label-troubleshoot-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](https://www.mongodb.com/docs/search/deployment/deployment-options.md#std-label-fts-architecture), 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 `mongot`. However, retaining network storage might not be possible in certain regions, when your cluster is using local NVMe (non-volatile memory express) 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 | Your Atlas instance might reboot during a new security policy rollout or if your cloud provider requires it. While Atlas reboots, if `mongod` starts before `mongot`, search queries fail until `mongot` is running.; Your Atlas instance might require a replacement if you have unhealthy hardware or if you've migrated system architectures. When you replace the instance, `mongot` performs an initial sync and search queries fail until the initial sync is complete. | | `mongot` Restart | Any time the `mongot` process restarts from configuration changes, search queries fail until `mongot` becomes available. | ## Production Environment For your production-ready application, we recommend using the deployment type and node architecture described in the following sections. This configuration is best suited for the following use cases: - If you choose to migrate your existing testing environment to production, add dedicated Search Nodes to your cluster. To learn more, see [Migrate to Dedicated Search Nodes.](https://www.mongodb.com/docs/search/deployment/deployment-options.md#std-label-fts-migrate-to-decoupled) - If you create a new production deployment from scratch, ensure that you use `M10` or larger tier clusters that support MongoDB Search in the regions and zones where MongoDB Search is available, and add dedicated Search Nodes to your environment. To learn more, see [Add Dedicated Search Nodes.](https://www.mongodb.com/docs/search/deployment/deployment-options.md#std-label-fts-add-search-nodes-to-prod) Deployment Type For production-ready applications, use `M10`, `M20`, and higher dedicated cluster tiers. These higher tier clusters can handle large datasets and production workloads. We recommend that you also [deploy dedicated Search Nodes](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-configure-search-nodes). If your search requirements increase, you can scale up your search deployment independently of scaling up the MongoDB nodes. Cloud Provider and Region Use Search Nodes in all Google Cloud regions and in a subset of AWS (Amazon Web Services) and Azure (Microsoft Azure) [regions](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-fts-cloud-provider-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 affect the configuration options and search tiers available for the cluster and the [cost of running the cluster.](https://www.mongodb.com/docs/atlas/billing.md#std-label-atlas-billing) ### Node Architecture For production environments, we recommend a node architecture in which MongoDB processes and MongoDB Search processes run on separate nodes. To deploy separate Search Nodes, see [Migrate to Dedicated Search Nodes.](https://www.mongodb.com/docs/search/deployment/deployment-options.md#std-label-fts-migrate-to-decoupled) In the following diagram of this deployment model, the MongoDB Search `mongot` process runs on dedicated Search Nodes, which are separate from the cluster nodes on which the `mongod` process runs. ![Separate Search Nodes architecture](/_includes/images/deployment/search-nodes-architecture.png) 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. To learn how MongoDB Search processes queries on this architecture, see [Query Processing.](https://www.mongodb.com/docs/search/query/query-ref.md#std-label-about-mongot) You can define [stored source](https://www.mongodb.com/docs/search/indexes/stored-source-definition.md#std-label-fts-stored-source-definition) fields in your MongoDB Search index so that the `mongot` process can store the specified fields on `mongot`. You can then use the [returnStoredSource Option](https://www.mongodb.com/docs/search/query/return-stored-source.md#std-label-fts-return-stored-source-option) in your MongoDB 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 scale the storage and compute independently of your MongoDB cluster. This allows you to also scale the query load independently of MongoDB. To scale Search Nodes horizontally, increase or reduce the number of Search Nodes. You can provision from a minimum of 2 up to a maximum of 32 Search Nodes per region per shard. To balance the query load, MongoDB Search distributes search queries across all available Search Nodes. To scale Search Nodes vertically, select different search tiers, CPU, RAM and storage configurations that support your full-text workloads. Performance When you deploy dedicated Search Nodes, you improve the performance and resource utilization for both the `mongod` and `mongot` processes and eliminate resource contention between these processes. Dedicated Search Nodes support [concurrent segment search](https://www.mongodb.com/docs/search/query/concurrent-query.md#std-label-concurrent-ref), which allows MongoDB Search to search multiple index segments at the same time. Using concurrent segment search improves query response time in some cases. Workload Isolation Deploying dedicated Search Nodes does not directly affect data transfer to the main database nodes. Search Nodes handle search queries separately from the main database operations, providing workload isolation while you incur network charges only for traffic between Search Nodes and database nodes. ### Tips for Sizing and Scaling Search Nodes To determine the memory requirements for Search Nodes, use the following Atlas metrics: - Size of the Search Index - Total RAM on the Search Node Consider an application that has a 10GB Search Index and 4GB total RAM on the Search Node. In this case, if 1GB of RAM is used by other processes and only 3GB are available for the index data, the remaining 7GB of the index data (10GB - 3GB = 7GB) is paged in, as needed, from the disk. Frequent paging from disk causes increased page faults, disk I/O, and CPU IOWait, resulting in performance degradation. If you use a higher search cluster tier with more RAM, such as 8GB or more, this allows Atlas to serve most of the data for the Search Index from memory, minimizing disk reads and page faults, thereby improving performance. **Note:** The local SSD (Solid State Disk)s 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 instances with high-performance local storage. 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.](https://www.mongodb.com/docs/atlas/billing/search-node.md#std-label-fts-search-node-costs) ### Enable Encryption at Rest By default, MongoDB and [search processes](https://www.mongodb.com/docs/search/query/query-ref.md#std-label-about-mongot) run on the same nodes. With this architecture, customer-managed encryption applies to your database data, but it does not apply to search indexes. When you enable [dedicated Search Nodes](https://www.mongodb.com/docs/search/deployment/deployment-options.md#std-label-what-is-search-node), search processes run on separate nodes. This allows you to enable [Search Node Data Encryption](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-enable-search-node-encryption), so you can encrypt both database data and search indexes with the same customer-managed keys for comprehensive encryption coverage. Dedicated Search Nodes are not supported on Atlas Infinite clusters clusters in public preview. **Note:** Database nodes and Search Nodes use different encryption methods with the same customer-managed keys. Database nodes use the [WiredTiger Encrypted Storage Engine](https://www.mongodb.com/docs/manual/core/security-encryption-at-rest.md#std-label-encrypted-storage-engine), while Search Nodes use encryption at the disk level. To learn more, see [Enable Customer Key Management for Search Nodes.](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-enable-search-node-encryption) ### Add Dedicated Search Nodes Adding dedicated Search Nodes to a new cluster allows you to: - Change the size and scale of your search deployment independently from your database deployment. - Eliminate resource contention that you might experience on a cluster that runs both the MongoDB database and search processes on the same node. To deploy dedicated Search Nodes, you must have [`Project Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Owner) access to the project. To add dedicated Search Nodes: 1. Create your cluster as an `M10` or higher tier in a cloud provider and region that supports node isolation. To learn more, see [Create an Atlas Infinite or Atlas Core Cluster.](https://www.mongodb.com/docs/atlas/tutorial/create-new-cluster.md#std-label-create-new-cluster) Dedicated Search Nodes are supported only for `M10` and higher cluster tiers and in [cloud provider regions that support node isolation.](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-fts-cloud-provider-regions) 2. Enable Search Nodes for workload isolation and [Configure Search Nodes.](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-add-search-nodes) ### Migrate to Dedicated Search Nodes To migrate from staging to production and add dedicated Search Nodes, make the following changes to your existing staging and prototyping deployment: 1. If your deployment uses a Flex cluster, [change the cluster tier to a higher tier](https://www.mongodb.com/docs/atlas/scale-cluster.md#std-label-scale-cluster-instance). Dedicated Search Nodes are supported only for `M10` and higher cluster tiers. 2. Deploy your cluster in regions where Search Nodes are also available. Dedicated Search Nodes are available on a subset of the AWS (Amazon Web Services) and Azure (Microsoft Azure) regions and in all supported Google Cloud regions. If your existing cluster is hosted in regions where Search Nodes aren't available, migrate your cluster to regions where Search Nodes are available. To learn more, see [Cloud Provider Regions that Support Node Isolation.](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-fts-cloud-provider-regions) 3. Enable Search Nodes for workload isolation and configure Search Nodes. To learn more, see [Add Search Nodes.](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-add-search-nodes) When you deploy dedicated Search Nodes, the following sequence of actions takes place: - Atlas builds the search indexes on the Search Nodes and removes the indexes from the cluster nodes. - Atlas routes search queries to the Search Nodes. - MongoDB Search uses the search indexes to serve queries on your cluster. ### Troubleshoot Deployment #### `Failed to Execute search Command` Error If you deploy `mongot` to run alongside `mongod` and **don't configure** Search Nodes, `mongot` might terminate and return the `Failed to Execute search Command` error during any of the following events: - Scaling up a cluster - Node failover - Upgrading `mongot` If you deploy `mongot` on dedicated Search Nodes, `mongod` uses a proxy that routes search queries only to the healthy nodes where the `mongot` process is active. ## MongoDB Community Edition If you run MongoDB Search on MongoDB Community Edition or another self-managed deployment, Atlas does not manage `mongot` for you. Instead, you install, configure, and operate `mongot` yourself. The following sections summarize the available architecture patterns and sizing options. For complete deployment and sizing guidance, see [MongoDB Search and MongoDB Vector Search on Self-Managed Deployments](https://www.mongodb.com/docs/search/self-managed/current.md#std-label-mongot-overview) and [Introduction to mongot Deployment Sizing.](https://www.mongodb.com/docs/search/self-managed/current/resource-planning-sizing/introduction.md#std-label-mongot-sizing-intro) ### Architecture Patterns As with MongoDB Search on Atlas, self-managed deployments use one of the same two architecture patterns: [co-located](https://www.mongodb.com/docs/search/self-managed/current/resource-planning-sizing/architecture.md#std-label-mongot-sizing-co-located) or [dedicated](https://www.mongodb.com/docs/search/self-managed/current/resource-planning-sizing/architecture.md#std-label-mongot-sizing-dedicated). The only exception is that on self-managed deployments, you provision and manage the hosts yourself. ### Sizing Unlike Atlas, self-managed deployments have no predefined cluster or search tiers. You provision your own hardware or cloud instances. To choose a starting configuration and refine it based on your workload, see [Introduction to mongot Deployment Sizing.](https://www.mongodb.com/docs/search/self-managed/current/resource-planning-sizing/introduction.md#std-label-mongot-sizing-intro)