Atlas Search Node sizing: high-CPU vs low-CPU vs storage-optimized classes
Parent: Platform Consolidation TCO (Atlas Search/Vector Search vs Separate Search or Vector DB) · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Atlas Search Node sizing: high-CPU vs low-CPU vs storage-optimized classes. Run status: COMPLETED.
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.
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]
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]
- 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]
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]
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]
- 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]
- 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]
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]
- 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]
- 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]
- 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]
- 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]
- 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]
Children
- No children recorded.