# Atlas Search index sync lag and search-node sizing > Source-anchored research for Atlas Search index sync lag and search-node sizing. Run status: COMPLETED. Parent: [MongoDB Query Optimization Tooling: Compass Explain, Atlas Query Insights and Performance Advisor](https://llms-explorer.com/tree/mongodb-query-optimization-tooling-compass-explain-atlas-query-insights-and-performance-advisor/) · 5 facets · 13 facts · page: https://llms-explorer.com/tree/atlas-search-index-sync-lag-and-search-node-sizing/ ## How it works - Diagnose lag by comparing Atlas Search replication-lag metrics with write volume, index size, Search Node CPU and memory or heap, and query load. Atlas recommends batching or throttling write bursts and increasing the oplog size on Atlas Core when the oplog window is the constraint; it recommends more Search Node CPU and memory when `mongot` is resource constrained. Independent monitoring guidance and a forum response also point operators to Atlas Search metrics and index status. (high confidence) — [source](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/atlas-search-alerts.md) - Diagnose lag by comparing Search Max Replication Lag with source write volume, the oplog window, and Search-node metrics such as Process CPU, Page Fault, Process Throttling, and Index Size. Atlas says write bursts can exhaust the oplog and recommends batching or throttling bulk writes; on Atlas Core, increasing oplog size gives `mongot` more time to catch up. More Search-node CPU and memory can help when `mongot` is the bottleneck, but Atlas also identifies source-cluster load, complex indexing work, and many indexes as causes, so increasing Search-node size alone might not clear lag. (high confidence) — [source](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/atlas-search-alerts.md) ## Measurements and reference values - Collection size is not a reliable proxy for Search-index size: mappings and features such as autocomplete can make an index much larger than its source data. MongoDB recommends estimating the index-to-collection ratio with representative sample data, then sizing memory against the measured index footprint and available Search-node RAM. If the index working set does not fit in memory, disk paging raises page faults and I/O wait. Current Atlas guidance also requires 20% local-SSD storage overhead for Search-node index operations. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/search/performance/index-performance.md) - MongoDB's August 2025 sizing post gives about 10 queries per second per vCPU as a rough starting estimate and sub-100 ms as a general latency aim. The post says actual throughput depends on query complexity and index mappings, so treat these as starting points for representative load tests, not capacity guarantees. (low confidence) (verified as of 2025-08-12) — [source](https://mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) - Atlas Search replication on dedicated Search Nodes pauses when disk utilization reaches 90% and resumes automatically below 85%. While replication is paused, nodes might continue serving queries with stale data, and prolonged pauses can lead to an oplog falloff and index rebuild. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/atlas-search-alerts.md) ## Problems, failure modes and limitations - Current Atlas deployment guidance permits 2 to 32 dedicated Search Nodes per region per shard. Operators can scale horizontally by changing the node count and vertically by selecting Search Node CPU, RAM, and storage tiers; the published node-count range is a product limit, not a sizing recommendation. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/search/deployment/deployment-options/) - Dedicated Search Nodes isolate `mongot` from `mongod` and let teams scale Search-node CPU, RAM, and storage independently of the database cluster. Atlas currently supports 2 to 32 dedicated Search Nodes per region per shard; that range is a product limit, not a sizing target. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/search/deployment/deployment-options.md) ## Comparisons and alternatives - Size Search Node memory against the Search Index footprint and available node RAM, rather than collection size alone. When the index data does not fit in memory, Atlas pages data from disk; repeated paging raises page faults, disk I/O, and CPU IOWait. More RAM can keep more index data in memory and reduce that pressure. (high confidence) — [source](https://www.mongodb.com/docs/search/deployment/deployment-options/) - When scaling dedicated Search Nodes without Customer Key Management encryption at rest, Atlas can seed a new node from a recent index copy in S3, Google Cloud Storage, or Azure Blob Storage instead of reconstructing every index file from the source collection. This can shorten scale or recovery work, but paused replication can delay or prevent fast provisioning and the snapshot path does not remove steady-state replication lag. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/search/performance/index-performance.md) ## Facts and statements - Atlas Search is eventually consistent: `mongot` indexes MongoDB change-stream updates asynchronously, so a recent write might not be visible to `$search` immediately. MongoDB lists replication latency, system-resource availability, index-definition complexity, complex view transformations, and many Search indexes as contributors to indexing delay or replication lag. (high confidence) — [source](https://www.mongodb.com/docs/search/performance/index-performance.md) - For the Atlas oplog-window alert case, if `mongot` falls behind the configured oplog window, it can no longer sync incrementally and Atlas automatically rebuilds the full index. The Atlas alert guide says queries continue during this rebuild but can return stale results. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/atlas-search-alerts.md) - Choose Search Node resources against distinct bottlenecks: large index footprints with moderate indexing and query rates favor storage-oriented capacity, while heavy ingestion or query loads need suitable CPU and disk I/O. Index mappings and features such as autocomplete change index size, and change-stream reads also consume resources on the MongoDB cluster, so scaling only Search Nodes may not clear lag caused on the source side. (high confidence) — [source](https://mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) - Dedicated Search Nodes isolate `mongot` from `mongod` and allow search compute, storage, and query capacity to scale independently. This reduces resource contention, but does not remove source-cluster change-stream load, write bursts, oplog-window limits, index complexity, or per-index replication overhead. (high confidence) — [source](https://www.mongodb.com/docs/search/deployment/deployment-options/)