Atlas Search and Dedicated Search Nodes Cost

Parent: Atlas Cluster Topology and Tier Economics · Published reference · snapshot 2026-10-19 · skill mongodb-operations-expert/references/atlas-cluster-topology-and-tier-economics.md · viability 3.60 / 5 (research)

Also known as: Search Node tier sizing from index size and QPS, Per-region Search Node counts

↓ Facts as markdown all context files

Atlas Search adds no fee when mongot is co-located with mongod, but co-located search shares cluster CPU and RAM and is documented for testing and prototyping, while dedicated Search Nodes need an M10+ cluster, a minimum of two nodes (up to 32 per region per shard) and bill per node-hour by tier and node class (high-CPU, low-CPU, storage-optimized). List prices differ by cloud (high-CPU S20 is $0.12/hr on AWS us-east-1, $0.14 on Google Cloud, $0.15 on Azure), search-to-database transfer appears under cluster network charges, and per-region node counts and the S10 tier are the newest cost levers. Drawn from 6 source pages, all MongoDB-authored, across measures, parameters, comparisons and problems; the pages disagree on the minimum production search tier (S20 versus the S10 announcement).

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

Definitions

What it is: MongoDB is introducing the S10 Dedicated Search Node, a new, lower-cost entry tier for Atlas Search and Vector Search that sits below the current S20 floor. S10 gives smaller and growing workloads their own dedicated, isolated compute for search, provisioned from the same Atlas search-node experience you already use. It's available today on all three cloud providers (AWS, GCP, Azure) that Atlas uses . [source] — S10 announcement 2026-07-23: S10 below S20
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. [source]
Atlas provides different search tiers. Each search tier has a default RAM capacity, storage capacity, and CPU. Each search node's per-hour usage charge (as shown in the Atlas UI during cluster creation) is calculated based on these default values. [source]
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. [source]
What it is: This functionality allows independent configuration of Dedicated Search Node counts across individual regions within a multi-region MongoDB Atlas cluster. Instead of maintaining identical node counts everywhere, a different number of nodes can be deployed in each region depending on regional requirements. [source]

How it works

Enabling Atlas Search on a cluster adds no fee when mongot is co-located with mongod, but co-located search consumes cluster CPU/RAM, and the docs warn of resource contention between mongod and mongot. The docs position co-located deployment for testing and prototyping. [source]
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. [source]
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. [source]
When you add a search node, Atlas charges you for the new configuration, including the new node, immediately. When you remove a search node, Atlas charges for the new configuration, excluding the node that you removed, immediately. Atlas charges you for a full hour even if you had a search node running for only part of the hour. If an unhealthy node is being replaced, Atlas doesn't charge for the replacement node and your charges will reflect the cost of only one node. [source]
With a traditional coupled architecture, this growth forces you to scale up your entire database cluster, leading to significant costs for compute resources you may not even need. Even with dedicated search nodes, which utilize fast but fixed-size local SSDs, you previously had to upgrade to a higher tier solely for more storage capacity. This often results in overprovisioning compute resources and inflating costs. For example, a customer needing the compute of an S50 node but the storage of an S70 could face a major price premium. [source]
When you create a cluster, Atlas calculates a per-hour usage charge based on the default values for the search tier. You can modify the search tier for your Search Nodes anytime. When you change instance size, Atlas charges for both instances for the first hour. After one hour, Atlas charges you for only the new instance. [source]
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. [source]
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. [source]
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 and $searchMeta for full-text search and $vectorSearch for semantic search in conjunction with other MongoDB aggregation pipeline stages, and score-based results ranking. [source]
When sizing your Atlas Search deployment, two key performance metrics are critical: Queries Per Second (QPS) and latency. [source]
For prototyping your application, use dedicated M10, M20, and higher tier clusters or deploy dedicated Search Nodes for workload isolation. When your application is ready for production and to handle large datasets, scale to higher tiers. [source]
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. [source]
When you first deploy the Search Nodes by clicking create in the Create New Cluster page, Atlas charges you immediately for your selected configuration. Atlas uses the following to calculate the cost of Search Nodes on your Atlas cluster: [source]
Indexing is the process of applying inserts, updates, and deletes from change streams to the search index. This can be resource-intensive, depending on ingest and update rates. Optimizing indexing involves considering both the cluster and the search node. [source]

Parameters and configuration

Dedicated Search Nodes require an M10+ cluster and a minimum of 2 nodes per cluster, up to 32 per region per shard. On sharded clusters Atlas deploys the node set per shard (2 nodes x 3 shards = 6 nodes), so the node floor multiplies with shard count. [source]
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. [source]
M10 or higher cluster tier and S20 or higher search tier [source] — Deployment-options page: S20 or higher
If your usage exceeds the listed values, migrate to dedicated search nodes. [source]
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. [source]
Dedicated Search Nodes are not supported on Atlas Infinite clusters clusters in public preview. [source]
Dedicated Search Nodes are supported only for M10 and higher cluster tiers and in cloud provider regions that support node isolation. [source]
If your deployment uses a Flex cluster, change the cluster tier to a higher tier. Dedicated Search Nodes are supported only for M10 and higher cluster tiers. [source]
Deploy your cluster in regions where Search Nodes are also available. Dedicated Search Nodes are available on a subset of the AWS and 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. [source]

How-to and procedures

To address this exact problem, MongoDB is introducing storage-optimized search nodes. These nodes are engineered for workloads where the footprint of your index is the main scaling factor, not high query rates or intense indexing operations. If your indexes are large but your query load is moderate, these nodes offer a cost-effective path to scale without overprovisioning. [source]
To scale Search Nodes vertically, select different search tiers, CPU, RAM and storage configurations that support your full-text workloads. [source]
Use this ratio to estimate the total index size based on your expected collection size. For instance, if a 1GB collection yields a 250MB index (a 0.25:1 ratio), a 12GB collection would likely result in an approximately 3GB index. If you already use Atlas Search, you can find the index size in cluster metrics or on the index list page. [source]
Use Search Nodes in all Google Cloud regions and in a subset of AWS and Azure regions. You must select a cloud provider and region where Search Nodes are available for your deployment. [source]

Measurements and reference values

On the MongoDB pricing page (updated 2026-09-29, AWS us-east-1) high-CPU Search Node prices run from S20 $0.12/hr (4 GB RAM, 2 vCPU, 106 GB) through S50 $0.99/hr to S80 $3.26/hr. Low-CPU S30 is $0.11/hr and storage-optimized S40-S is $0.25/hr. Because of the two-node minimum, the floor is about double the listed S20 rate (about $0.24/hr, roughly $175/month, derived). [source]
Sizing rule of thumb from MongoDB: about 10 QPS per vCPU (two S20 nodes = 4 vCPU = about 40 QPS); target latency under 100 ms; if adding CPU lowers latency the deployment is underprovisioned; scale out to up to 32 nodes for throughput; consider sharding above roughly 10k inserts/updates per second. These are vendor estimates, not benchmarks. [source]
Search Node price varies by cloud for the same tier name: high-CPU S20 is $0.12/hr on AWS us-east-1, $0.14/hr on Google Cloud us-central1, $0.15/hr on Azure eastus2; S50 is $0.99, $1.15 and $1.27/hr respectively. Storage per tier also differs by cloud (S20: 106, 128, 80 GB). [source]
Search Nodes run on compute-intensive instances with local SSDs that need about 20% storage overhead, so index size must fit the fixed per-tier disk. Index size depends on field mappings; estimate by indexing 1-2 GB of representative data (example ratio 0.25:1). [source]
Queries per second (QPS): This measures sustained query throughput. A general starting point for estimation is 10 QPS per vCPU core. For example, a minimum setup of two S20 nodes (each with 2 vCPUs) provides 4 vCPUs, supporting roughly 40 QPS. This is a baseline; query complexity and index mappings will influence actual QPS. QPS is supported by horizontal scaling; you can deploy up to 32 Search Nodes per cluster/shard/region to increase the overall vCPU count. [source]
| Cluster Tier | Storage (GB) | RAM (GB) | vCPUs | Base Price[1] | | --- | --- | --- | --- | --- | | S20 | 106 GB | 4 GB | 2 vCPUs | $0.12/hr | | S30 | 213 GB | 8 GB | 4 vCPUs | $0.24/hr | | S40 | 426 GB | 16 GB | 8 vCPUs | $0.48/hr | | S50 | 855 GB | 32 GB | 16 vCPUs | $0.99/hr | | S60 | 1710 GB | 64 GB | 32 vCPUs | $1.77/hr | | S70 | 2564 GB | 96 GB | 48 vCPUs | $2.50/hr | | S80 | 3420 GB | 128 GB | 64 vCPUs | $3.26/hr | [source]
| Cluster Tier | Storage (GB) | RAM (GB) | vCPUs | Base Price[1] | | --- | --- | --- | --- | --- | | S30 | 53 GB | 8 GB | 1 vCPUs | $0.11/hr | | S40 | 106 GB | 16 GB | 2 vCPUs | $0.21/hr | | S50 | 213 GB | 32 GB | 4 vCPUs | $0.43/hr | | S60 | 426 GB | 64 GB | 8 vCPUs | $0.89/hr | | S80 | 855 GB | 128 GB | 16 vCPUs | $1.68/hr | | S90 | 1710 GB | 256 GB | 32 vCPUs | $3.12/hr | | S100 | 2564 GB | 384 GB | 48 vCPUs | $4.40/hr | | S110 | 3420 GB | 512 GB | 64 vCPUs | $5.87/hr | [source]
| Cluster Tier | Storage (GB) | RAM (GB) | vCPUs | Base Price[1] | | --- | --- | --- | --- | --- | | S20 | 128 GB | 4 GB | 2 vCPUs | $0.14/hr | | S30 | 337 GB | 8 GB | 4 vCPUs | $0.27/hr | | S40 | 362 GB | 16 GB | 8 vCPUs | $0.57/hr | | S50 | 674 GB | 32 GB | 16 vCPUs | $1.15/hr | | S60 | 1348 GB | 64 GB | 32 vCPUs | $2.22/hr | [source]
| Cluster Tier | Storage (GB) | RAM (GB) | vCPUs | Base Price[1] | | --- | --- | --- | --- | --- | | S30 | 128 GB | 8 GB | 2 vCPUs | $0.16/hr | | S40 | 337 GB | 16 GB | 2 vCPUs | $0.24/hr | | S50 | 337 GB | 32 GB | 4 vCPUs | $0.43/hr | | S60 | 337 GB | 64 GB | 8 vCPUs | $0.87/hr | | S70 | 674 GB | 96 GB | 12 vCPUs | $1.24/hr | | S80 | 674 GB | 128 GB | 16 vCPUs | $1.79/hr | | S90 | 1348 GB | 256 GB | 32 vCPUs | $3.45/hr | [source]
| Cluster Tier | Storage (GB) | RAM (GB) | vCPUs | Base Price[1] | | --- | --- | --- | --- | --- | | S20 | 80 GB | 4 GB | 2 vCPUs | $0.15/hr | | S30 | 161 GB | 8 GB | 4 vCPUs | $0.30/hr | | S40 | 322 GB | 16 GB | 8 vCPUs | $0.62/hr | | S50 | 644 GB | 32 GB | 16 vCPUs | $1.27/hr | | S60 | 1288 GB | 64 GB | 32 vCPUs | $2.29/hr | | S70 | 1932 GB | 96 GB | 48 vCPUs | $3.23/hr | | S80 | 2576 GB | 128 GB | 64 vCPUs | $4.22/hr | [source]
| Cluster Tier | Storage (GB) | RAM (GB) | vCPUs | Base Price[1] | | --- | --- | --- | --- | --- | | S40 | 80 GB | 16 GB | 2 vCPUs | $0.23/hr | | S50 | 161 GB | 32 GB | 4 vCPUs | $0.47/hr | | S60 | 322 GB | 64 GB | 8 vCPUs | $0.98/hr | | S80 | 644 GB | 128 GB | 16 vCPUs | $1.87/hr | | S90 | 1288 GB | 256 GB | 32 vCPUs | $3.48/hr | | S100 | 1932 GB | 384 GB | 48 vCPUs | $4.92/hr | | S110 | 2576 GB | 512 GB | 64 vCPUs | $6.55/hr | | S130 | 3865 GB | 672 GB | 96 vCPUs | $9.83/hr | | S135 | 4080 GB | 672 GB | 104 vCPUs | $11.71/hr | [source]
Latency: This is the time between query execution and response receipt. The general aim is sub-100ms latency, though some cases demand much lower latency. Latency is a function of DSN resources and can be improved by vertical scaling (moving to a higher search node tier). Sufficient CPU, RAM, and disk I/O are essential. CPU is primarily leveraged for queries using concurrent segment search; if adding CPU resources reduces latency, it indicates underprovisioning. [source]
Since 2026-06-30 (GA), multi-region clusters can set a different dedicated Search Node count per region. MongoDB estimates 25-40% lower Search Node spend where secondary regions carry little search traffic. The figure is a vendor estimate. Use it to avoid duplicating full node counts in DR regions. [source]
The deployment-options page tells users to move to dedicated Search Nodes once they exceed roughly 2 million documents to index, 10 GB of indexed data, or 10,000 queries in 7 days. [source]
| Cluster Tier | Storage (GB) | RAM (GB) | vCPUs | Base Price[1] | | --- | --- | --- | --- | --- | | S40-S | 421 GB | 16 GB | 2 vCPUs | $0.25/hr | | S50-S | 843 GB | 32 GB | 4 vCPUs | $0.52/hr | | S60-S | 1687 GB | 64 GB | 8 vCPUs | $0.94/hr | | S80-S | 3375 GB | 128 GB | 16 vCPUs | $1.89/hr | | S90-S | 6750 GB | 256 GB | 32 vCPUs | $3.76/hr | [source]
The local SSDs used for Search Nodes require a 20% storage overhead to support index operations. [source]
High-CPU2:1 RAM:vCPU ratioFT/Lexical search, Vector Search, Heavy indexing, Heavy query load100 - 3200 GB [source]
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. [source]
Why it matters: Matching Search Node capacity to actual regional traffic patterns eliminates the cost of over-provisioning secondary environments. This adjustment lowers total Search Node expenditures for multi-region deployments by an estimated 25% to 40%, depending on the cluster topology. [source]

Problems, failure modes and 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. [source]
If mongod starts before mongot, MongoDB Search queries fail until mongot is running. [source]
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: [source]
Eliminate resource contention that you might experience on a cluster that runs both the MongoDB database and search processes on the same node. [source]

Comparisons and alternatives

Three node classes trade RAM:vCPU and storage: low-CPU 8:1 (vector search, low data volume), high-CPU 2:1 (lexical search, heavy indexing/query), storage-optimized 8:1 with 375-6000 GB (large indexes, moderate load). MongoDB claims storage-optimized nodes cut Search Node storage cost up to 50% and are about 40% cheaper than high-CPU when RAM-anchored. List prices agree in direction: AWS S40-S $0.25/hr vs high-CPU S40 $0.48/hr, both 16 GB RAM. Choose storage-optimized when storage is the constraint and CPU is moderate. [source]
To solve this and provide more cost-effective scaling, we are introducing storage-optimized search nodes. These nodes are designed specifically for use cases where large index sizes are the primary scaling factor, rather than high computational demands from indexing or querying. [source]
For a large-scale vector search deployment using BQ that requires 3600GB of storage, you can now select a storage-optimized node that fits your needs precisely, rather than drastically overprovisioning a high-CPU node just for its disk space. This alignment of resources to workload ensures you can build and scale modern AI applications efficiently and economically. [source]
Cost-effectiveness: These nodes can save up to 50% on DSN storage costs and are approximately 40% less expensive than existing high-CPU nodes when anchored on RAM. At the same vCPU count, users receive roughly 3x the storage compared to high-CPU nodes. [source]
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. [source]

Facts and statements

Search Nodes bill hourly per node, and a partial hour counts as a full hour. Adding or removing a node bills the new configuration immediately. Changing tier bills both old and new instances for the first hour. A replacement of an unhealthy node is free. Network charges cover traffic between Search Nodes and database nodes and appear at cluster level, not as a Search Node line item. [source]
MongoDB announced an S10 Dedicated Search Node tier on 2026-07-23 on AWS, GCP and Azure as a lower-cost entry below S20, aimed at M10/M20/M30 clusters. The announcement gives no price or spec, and the deployment-options page still states S20 as the production minimum. [source]
The first consideration is your index size. Dedicated search nodes (DSN) utilize local solid-state drives (SSDs) of a fixed size. Therefore, a DSN must possess adequate disk space for the index. It's crucial to remember that a collection's size and the resulting search index's size are not always directly related due to index mapping. For example, if your documents have 100 fields but your search index is configured for only 5, the index will be substantially smaller than the collection. Conversely, mapping all fields or using features like autocomplete can significantly increase index size. [source]
How to get started: From your Atlas cluster, add Dedicated Search Nodes and select the S10 tier. See the documentation link below for a step-by-step guide. [source]
Search Node cost is additive to the base cluster: node count x tier rate, plus search-to-database transfer billed under cluster network charges. Pricing-page cluster rates do not include Search Nodes, so model them as a separate line (the sibling multi-region transfer concept covers network cost). [source]
DSN indexing: Search Nodes use high-performance local disks. Each tier offers higher input/output per second (IOPS). If you observe high vCPU utilization with heavy insert rates, upgrading to a higher DSN tier might be beneficial. [source]
Why it matters: Dedicated Search Nodes isolate search and vector search workloads from your database so each can scale independently and deliver better performance and higher availability. Until now, the lowest dedicated tier priced smaller workloads out of those benefits. S10 closes that gap, offering a low-cost on-ramp to workload isolation: start on dedicated nodes early, then scale up as your search workload grows. [source]
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. [source]
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. [source]
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. [source]
For clusters on AWS, Google Cloud, or Azure, Atlas supports deploying separate Search Nodes for MongoDB Search. [source]
You will see the charges for data transfer at the cluster level. Atlas doesn't reflect the charges for the Search Nodes separately. Your network charges reflect the cost of the whole Atlas cluster, including the Search Nodes. [source]
Who it's for: This is for developers and architects running M10, M20, and M30 Atlas clusters who want to separate search from database resources for more predictable performance, but couldn't previously justify the cost of stepping up to an S20 node. [source]
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. [source]
The rise of AI has put a new focus on vector search. While traditionally memory-constrained, modern techniques like automatic binary quantization are shifting the bottleneck from RAM to storage. Binary quantization makes indexes more storage-constrained, and storage-optimized nodes are the perfect solution. [source]
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. [source]
We recommend that you also deploy dedicated Search Nodes. If your search requirements increase, you can scale up your search deployment independently of scaling up the MongoDB nodes. [source]
Atlas builds the search indexes on the Search Nodes and removes the indexes from the cluster nodes. [source]
Atlas routes search queries to the Search Nodes. [source]
You will be charged for network traffic between Search Nodes and the database nodes on your Atlas cluster. 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, allowing for workload isolation. [source]
Who it's for: This feature is designed for database administrators and infrastructure teams managing multi-region Atlas clusters that experience asymmetric search traffic, such as high-volume primary regions paired with secondary regions used mainly for availability or disaster recovery. [source]
How to get started: Per-region node counts can be configured directly within the Atlas cluster builder or updated through the Atlas Administration API. [source]

Disagreements

What it is: MongoDB is introducing the S10 Dedicated Search Node, a new, lower-cost entry tier for Atlas Search and Vector Search that sits below the current S20 floor. S10 gives smaller and growing workloads their own dedicated, isolated compute for search, provisioned from the same Atlas search-node experience you already use. It's available today on all three cloud providers (AWS, GCP, Azure) that Atlas uses . [source] — S10 announcement 2026-07-23: S10 below S20
M10 or higher cluster tier and S20 or higher search tier [source] — Deployment-options page: S20 or higher
MongoDB announced an S10 Dedicated Search Node tier on 2026-07-23 on AWS, GCP and Azure as a lower-cost entry below S20, aimed at M10/M20/M30 clusters. The announcement gives no price or spec, and the deployment-options page still states S20 as the production minimum. [source]

Related concepts

S20 — is a part of Atlas Search and Dedicated Search Nodes Cost
MongoDB Search — is a synonym of Atlas Search and Dedicated Search Nodes Cost
vector search nodes — is a related of Atlas Search and Dedicated Search Nodes Cost
high-CPU — is a hyponym of Atlas Search and Dedicated Search Nodes Cost
Base Price — is a measure of Atlas Search and Dedicated Search Nodes Cost
storage-optimized — is a hyponym of Atlas Search and Dedicated Search Nodes Cost
index size — is a measure of Atlas Search and Dedicated Search Nodes Cost
low-CPU — is a hyponym of Atlas Search and Dedicated Search Nodes Cost
two-node minimum — is a measure of Atlas Search and Dedicated Search Nodes Cost
resource contention — is a problem of Atlas Search and Dedicated Search Nodes Cost
S10 tier — is a instance of Atlas Search and Dedicated Search Nodes Cost
search network charges — is a related of Atlas Search and Dedicated Search Nodes Cost
DSN — is a abbreviation of Atlas Search and Dedicated Search Nodes Cost
QPS — is a measure of Atlas Search and Dedicated Search Nodes Cost
asymmetric per-region — is a hyponym of Atlas Search and Dedicated Search Nodes Cost
per shard — is a related of Atlas Search and Dedicated Search Nodes Cost
co-located — is a hyponym of Atlas Search and Dedicated Search Nodes Cost
node-hour — is a measure of Atlas Search and Dedicated Search Nodes Cost
price varies by cloud — is a related of Atlas Search and Dedicated Search Nodes Cost
unhealthy node — is a related of Atlas Search and Dedicated Search Nodes Cost

Children

Co-located vs dedicated search migration thresholds

← the whole tree · 3D view· how to read this page