# Dedicated Search Node storage and compute sizing > Source-anchored research for Dedicated Search Node storage and compute sizing. Run status: COMPLETED. Parent: [Atlas Search index sync lag and search-node sizing](https://llms-explorer.com/tree/atlas-search-index-sync-lag-and-search-node-sizing/) · 6 facets · 22 facts · page: https://llms-explorer.com/tree/dedicated-search-node-storage-and-compute-sizing/ ## Structure and components - Total node RAM exceeds the memory available for index caching because heap and auxiliary processes consume part of it. When index pages must be repeatedly read from disk, page faults, disk I/O, and CPU IOWait can rise; evaluate these together when deciding whether more RAM addresses a bottleneck. (medium confidence) — [source](https://www.mongodb.com/docs/search/deployment/deployment-options.md) ## How it works - MongoDB Search uses JVM heap for query and indexing objects and filesystem cache for memory-mapped index files. Apache Lucene independently documents memory-mapped file reads and optional physical-memory preloading; this supports the caching mechanism, not an Atlas-specific heap allocation formula. (medium confidence) — [source](https://www.mongodb.com/docs/search/performance/index-performance.md) - Search Node count is provisioned per database shard: MongoDB gives the example that two Search Nodes for each of three shards produce six Search Nodes. Account for that multiplication when estimating the fleet resource footprint. (low confidence) — [source](https://www.mongodb.com/docs/search/deployment/deployment-options.md) - Apache Lucene 9.8.0 documents that mapping an index file consumes virtual address space equal to the file size and distinguishes that mapping from optional loading into physical memory. Consequently, mapped virtual bytes alone are not a measurement of heap demand or the resident working set; this is a Lucene mechanism, not evidence of the Lucene version deployed by Atlas. (low confidence) — [source](https://lucene.apache.org/core/9_8_0/core/org/apache/lucene/store/MMapDirectory.html) ## Measurements and reference values - Estimate search-index storage using representative data and the intended mappings. MongoDB suggests building an index over 1–2 GB and extrapolating the measured index-to-collection ratio; indexing more fields and generating autocomplete tokens can enlarge the footprint. (medium confidence) — [source](https://www.mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) - MongoDB documents a 20% storage overhead for Search Node local SSD index operations. Treat this as operational overhead guidance, not proof that the remaining capacity accommodates every rebuild or future growth scenario. (low confidence) (verified as of 2026-10-27) — [source](https://www.mongodb.com/docs/search/deployment/deployment-options.md) - Dedicated Search Nodes pause replication at 90% disk utilization and resume below 85%; queries can continue with stale data. Storage headroom therefore protects index freshness as well as capacity. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/atlas-search-alerts/) - MongoDB publishes roughly 10 sustained QPS per vCPU as a starting estimate, illustrated by about 40 QPS across four vCPUs. Its August 12, 2025 article explicitly makes actual throughput dependent on query complexity and index mappings; the number is not a capacity guarantee. (low confidence) (verified as of 2025-08-12) — [source](https://www.mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) - On dedicated Search Nodes, MongoDB documents an approaching-stop alert at disk utilization of at least 85%, replication pause at 90%, and automatic resumption below 85%. Queries may continue while data becomes stale; prolonged pauses can exhaust the oplog window and force an index rebuild. (low confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/atlas-search-alerts/) ## Problems, failure modes and limitations - A firsthand operator report describes Search Node OOM events causing failed search queries. The thread supplies no root cause, workload measurements or validated node-sizing remedy, so it cannot establish a capacity formula. (low confidence) — [source](https://www.reddit.com/r/mongodb/comments/1t5c3qf/looking_for_root_cause_for_search_nodes_crashing/) ## Comparisons and alternatives - Increasing Search Node count distributes query load, while increasing per-node CPU, RAM, and storage resources addresses individual-node limits. MongoDB distinguishes horizontal throughput scaling from vertical resource scaling; diagnose the limiting resource rather than sizing on index bytes alone. (medium confidence) — [source](https://www.mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) ## Facts and statements - Dedicated Atlas Search Nodes let operators scale search compute separately from database compute. Index storage, query load, and indexing load each affect the required search capacity. (medium confidence) — [source](https://www.mongodb.com/docs/search/deployment/deployment-options.md) - RAM sizing must leave space for other processes. MongoDB’s example pages index data exceeding available RAM from disk; frequent paging increases page faults, disk I/O and CPU IOWait. Whole-index residency is not presented as a hard requirement for serving queries. (low confidence) — [source](https://www.mongodb.com/docs/search/deployment/deployment-options.md) - Measure query throughput and latency separately: MongoDB describes adding Search Nodes for throughput and increasing per-node resources for latency, with CPU, RAM and disk I/O all relevant. (low confidence) — [source](https://www.mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) - Initial indexing and ongoing synchronization also consume database-side read capacity. Sizing only Search Nodes can leave the database unable to feed indexing fast enough. (medium confidence) — [source](https://www.mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) - Alibaba Cloud independently documents selecting mongot compute by expected QPS and data complexity, and index disk by volume, complexity and growth headroom. This supports the sizing method, but its product configuration is not an Atlas sizing specification. (low confidence) — [source](https://help.aliyun.com/en/mongodb/user-guide/mongodb-search) - AWS’s OpenSearch sizing guidance independently considers data growth, storage reserves, query concurrency and CPU/memory balance. These are useful planning dimensions; its replica/storage formula and instance recommendations do not establish Atlas Search Node requirements. (low confidence) (verified as of 2026-02-16) — [source](https://aws.amazon.com/blogs/big-data/amazon-opensearch-service-101-t-shirt-size-your-domain-for-e-commerce-search/) - Index rebuilds can require simultaneous old and new index versions: no-downtime indexing keeps the old index serving while the new index builds, and insufficient disk space is an explicit alert condition. Budget rebuild capacity separately from steady-state index bytes. (medium confidence) — [source](https://www.mongodb.com/docs/search/performance/index-performance.md) - Validate an initial sizing estimate under the actual workload before treating it as production capacity. MongoDB qualifies its throughput heuristic by query complexity and mappings; AWS independently recommends load-testing and iterating its OpenSearch sizing. This is methodological corroboration, not an OpenSearch-to-Atlas performance conversion. (medium confidence) — [source](https://www.mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) - Provision for indexing as well as queries. Heavy insert/update activity can consume Search Node CPU, and insufficient replication resources can increase index lag. MongoDB recommends considering larger Search Nodes for additional CPU and memory and reducing write bursts where appropriate. (medium confidence) — [source](https://www.mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) - A sufficiently sized Search Node does not establish a guaranteed subsecond sync SLA. MongoDB describes subsecond replication as a goal, while its performance documentation guarantees only eventual consistency and identifies resource availability, mapping complexity, and database change-stream delivery as influences on latency. (medium confidence) — [source](https://www.mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) - AWS separately sizes OpenSearch storage for replicas, indexing overhead, operating-system reserves, service reserves, and growth. Its raw-bytes × (1 + replicas) × 1.45 example belongs to OpenSearch; it is comparative evidence for accounting for overhead, not an Atlas Search disk-sizing formula. (low confidence) (verified as of 2026-02-16) — [source](https://aws.amazon.com/blogs/big-data/amazon-opensearch-service-101-t-shirt-size-your-domain-for-e-commerce-search/)