Search Node tier selection: S10, High-CPU vs Low-CPU vs storage-optimized
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 Search Node tier selection: S10, High-CPU vs Low-CPU vs storage-optimized. 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
- When downsizing, the selected tier must fit existing search indexes plus extra disk space for bumper files and logs. A tier whose advertised disk barely matches index size is therefore not sufficient evidence that downsizing is supported. (low confidence) (verified as of 2026-10-14) [source]
Measurements and reference values
- The configuration documentation still defaults to S20. It recommends S10 for small workloads with index footprints under 10 GB and recommends S20 or higher for large indexes or query-intensive workloads; the 10 GB recommendation is not the advertised physical disk capacity. (low confidence) (verified as of 2026-10-14) [source]
Problems, failure modes and limitations
- Operator support can lag Atlas tier availability: issue 3168 reported missing storage-optimized Search Node support and records the fix in Atlas Kubernetes Operator v2.13.2. This is historical evidence of a tooling gate, not evidence that the limitation persists. (low confidence) (verified as of 2026-02-13) [source]
Comparisons and alternatives
- MongoDB positions High-CPU for lexical search, heavy indexing and heavy query load; Low-CPU for memory-oriented vector workloads with smaller storage needs; and storage-optimized for large indexes with moderate indexing and query load. These are workload profiles rather than universal performance rankings. (medium confidence) [source]
- A vector workload that fits in RAM can still benefit from High-CPU: MongoDB's example prefers S20 High-CPU over S30 Low-CPU for roughly 3 GB of vectors because it offers more CPUs for concurrent queries; the AWS table lists 2 versus 1 vCPU respectively. (medium confidence) (verified as of 2026-10-14) [source]
- The 2025 sizing blog's nominal High-CPU 2:1 RAM-to-vCPU ratio has an S10 exception in the later AWS table: S10 High-CPU has 4 GiB RAM, 1 vCPU and 54 GiB disk. Use the actual tier table instead of extrapolating the class ratio to S10. (medium confidence) (verified as of 2026-10-14) [source]
- The AWS High-CPU table lists S10 at 4 GiB RAM, 54 GiB storage and 1 vCPU, versus S20 at 4 GiB RAM, 98 GiB storage and 2 vCPUs. Moving from S10 to S20 therefore adds CPU and disk without adding RAM. (low confidence) (verified as of 2026-10-14) [source]
- Low-CPU is a starting point for memory-heavy vector workloads without quantization. High-CPU is intended for heavy query or indexing demand, including lexical search. Storage-optimized targets large index footprints with moderate indexing and query demand; these are workload heuristics rather than measured performance guarantees. (medium confidence) [source]
- The advertised class ratios are approximately 8 GiB RAM per vCPU for Low-CPU and storage-optimized, versus 2 GiB per vCPU for High-CPU. Apply these as class tendencies: AWS S10 is an explicit 4 GiB/1-vCPU exception. (medium confidence) (verified as of 2026-10-14) [source]
- Tier selection must respect cloud and region availability. AWS documentation lists regions restricted to Low-CPU; the configuration guide says an unavailable requested AWS tier can be replaced by the next higher available tier. Check the resulting deployment rather than assuming the requested tier was provisioned. (medium confidence) (verified as of 2026-10-14) [source]
Facts and statements
- MongoDB introduced S10 on July 23, 2026 as a lower-cost dedicated Search and Vector Search tier below S20, targeting smaller workloads on M10–M30 clusters; the announcement names AWS, Google Cloud and Azure. (medium confidence) (verified as of 2026-07-23) [source]
- Choose the hardware class as well as the S-number: AWS S40 has 16 GiB RAM in all three classes, but Low-CPU has 2 vCPUs/98 GiB storage, High-CPU has 8 vCPUs/396 GiB, and storage-optimized has 2 vCPUs/392 GiB. An S40 label alone does not specify equivalent resources. (medium confidence) (verified as of 2026-10-14) [source]
- A practitioner's Terraform deployment failed with INVALID_ENUM_VALUE for S40_STORAGE_OPTIMIZED and succeeded with S40_STORAGE_NVME. The operator issue independently documents the AWS enums S40_STORAGE_NVME, S50_STORAGE_NVME, S60_STORAGE_NVME, S80_STORAGE_NVME and S90_STORAGE_NVME. (medium confidence) (verified as of 2026-10-30) [source]
- Quantization does not imply that storage-optimized is always the best class. MongoDB recommends both High-CPU and storage-optimized for quantized workloads, with High-CPU favoring high QPS; its benchmark uses S50 storage-optimized for scalar quantization and S30 High-CPU for binary quantization. (low confidence) (verified as of 2026-10-14) [source]
- Pulumi configures a dedicated SearchDeployment with separate specs.instanceSize and specs.nodeCount fields; its example uses S20_HIGHCPU_NVME. Its field documentation defers valid instance-size values to the Atlas API, so a display label such as S20 is not a complete configuration identifier. (low confidence) (verified as of 2026-10-30) [source]
- In a firsthand Terraform deployment account, Ryan reports INVALID_ENUM_VALUE for S40_STORAGE_OPTIMIZED and S40_STORAGEOPTIMIZED. He reports success with S40_STORAGE_NVME and lists S50_STORAGE_NVME, S60_STORAGE_NVME, S80_STORAGE_NVME and S90_STORAGE_NVME as the storage-optimized identifiers. This is practitioner evidence, not an exhaustive current API enum specification. (low confidence) (verified as of 2026-07-20) [source]
Children
- Search Node instance-size API identifiers (frontier)
- Provider and region compatibility of Search Node hardware classes (frontier)
Frontier under this node: Provider and region compatibility of Search Node hardware classes, Search Node instance-size API identifiers