# Atlas Search Node sizing: high-CPU vs low-CPU vs storage-optimized classes > Source-anchored research for Atlas Search Node sizing: high-CPU vs low-CPU vs storage-optimized classes. Run status: COMPLETED. Parent: [Platform Consolidation TCO (Atlas Search/Vector Search vs Separate Search or Vector DB)](https://llms-explorer.com/tree/platform-consolidation-tco-atlas-search-vector-search-vs-separate-search-or-vector-db/) · 5 facets · 13 facts · page: https://llms-explorer.com/tree/atlas-search-node-sizing-high-cpu-vs-low-cpu-vs-storage-optimized-classes/ ## How it works - Class names do not ensure equivalent resources across services: AWS recommends its OpenSearch storage-optimized instance families for I/O-heavy work and frequent indexing, whereas MongoDB positions Atlas storage-optimized nodes for large indexes with moderate indexing. Compare actual CPU, RAM, storage and workload results in a consolidation model. (medium confidence) — [source](https://www.mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) ## Measurements and reference values - MongoDB recommends RAM at least 10% above total vector-index size and sufficient CPUs for internal query concurrency. Its example prefers high-CPU S20 over low-CPU S30 for approximately 3 GB of 768-dimensional vectors, despite both having enough RAM. Memory fit alone is insufficient to select a class. (high confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/docs/vector-search/deployment/deployment-options.md) - MongoDB recommends estimating search-index size from a representative 1–2 GB sample using the intended mappings, then extrapolating the index-to-collection ratio. Index mappings and autocomplete can materially change disk demand; collection size alone is insufficient. (low confidence) — [source](https://www.mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) ## Problems, failure modes and limitations - Cloud-specific capacity tables limit generalization: cached Google Cloud S30 low-CPU lists 8 GiB RAM, 2 vCPUs and 128 GiB disk, while AWS S30 low-CPU lists 8 GiB, 1 vCPU and 49 GiB. Google Cloud and Azure cached tables describe low/high-CPU classes without a storage-optimized table; this absence does not establish global unavailability. (medium confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/docs/atlas/reference/amazon-aws.md) ## Comparisons and alternatives - The AWS S50 table implies approximately four times the storage for storage-optimized versus low-CPU at the same RAM and CPU count, but similar storage and one quarter the CPUs versus high-CPU at the same RAM. Comparisons must state which resource is held constant. (low confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/docs/atlas/reference/amazon-aws.md) - The August 2025 launch article advertises up to 50% lower Search Node storage costs and approximately 40% lower cost at equal RAM versus high-CPU. These are vendor estimates, not measured savings for an arbitrary deployment or proof of equal throughput. (low confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) - MongoDB monitoring guidance treats sustained normalized search CPU below 20% as a possible downsize signal and above 80% as a possible upsize signal, while warning that signals depend on workload baselines. These are operational heuristics rather than class-selection thresholds or throughput guarantees. (low confidence) (verified as of 2026-10-31) — [source](https://medium.com/mongodb/monitoring-atlas-search-the-key-metrics-66c90c39d480) ## Facts and statements - MongoDB positions high-CPU nodes for lexical search, heavy indexing and high query load; low-CPU nodes prioritize memory for vector workloads; storage-optimized nodes target large indexes with moderate indexing and query rates. These are starting profiles, not workload-independent performance guarantees. (medium confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) - In the cached AWS Americas S50 table, low-CPU provides 32 GiB RAM, 4 vCPUs and 198 GiB storage; high-CPU provides 32 GiB, 16 vCPUs and 796 GiB; storage-optimized provides 32 GiB, 4 vCPUs and 785 GiB. Thus the same tier name does not imply the same CPU or disk capacity. (low confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/docs/atlas/reference/amazon-aws.md) - A July 2026 practitioner account reports that Terraform instance_size values S40_STORAGE_OPTIMIZED and S40_STORAGEOPTIMIZED failed with HTTP 400 INVALID_ENUM_VALUE. The author reports successful deployment with S40_STORAGE_NVME and lists S50/S60/S80/S90_STORAGE_NVME. This is a historical implementation observation; verify the deployed provider/API version before reuse. (low confidence) (verified as of 2026-10-31) — [source](https://cultivatingsoftware.wordpress.com/author/ryanvgates/) - A February 6, 2026 report against Atlas Kubernetes Operator v2.6.1 asks for storage-optimized Search Node support. It demonstrates that Atlas service availability and deployment-tool support can differ; the issue body does not establish present support or the release that resolved it. (low confidence) (verified as of 2026-10-31) — [source](https://github.com/mongodb/mongodb-atlas-kubernetes/issues/3168) - The AWS table snapshot lists S40 low-CPU as 16 GiB RAM, 98 GiB storage and 2 vCPUs; S40 high-CPU as 16 GiB, 396 GiB and 8 vCPUs; and S40 storage-optimized as 16 GiB, 392 GiB and 2 vCPUs. At equal S40 RAM, storage-optimized provides approximately four times low-CPU storage, while high-CPU provides four times its CPU count. These are AWS-specific specifications, not universal cloud ratios. (low confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/docs/atlas/reference/amazon-aws.md) - MongoDB recommends sampling representative data with the intended mappings to estimate search-index size; collection size alone can mislead. For TCO modelling, infer the required class from index storage, memory and query demand, then validate the workload. AWS independently recommends workload-based sizing and load testing for its own search service; it supplies no Atlas class benchmark. (medium confidence) — [source](https://www.mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes)