Search Node sizing for quantized vector indexes (RAM, disk, vCPU)
Parent: Atlas Vector Search automatic quantization and rescoring · Published reference · snapshot 2026-10-30
↓ Facts as markdownall context files
Source-anchored research for Search Node sizing for quantized vector indexes (RAM, disk, vCPU). 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.
Problems, failure modes and limitations
- Select CPU capacity against measured throughput as well as RAM fit: MongoDB's binary benchmark reports reduced throughput under heavy concurrency from rescoring, while Qdrant warns that rescoring disk-resident originals can significantly slow searches. RAM savings alone do not establish the cheapest deployment at the required service level. (medium confidence) [source]
Comparisons and alternatives
- MongoDB documents approximately 3.75-fold scalar and 24-fold binary reductions in vector-index RAM requirements, rather than assuming that nominal 4-fold and 32-fold component compression applies to the whole index. Its deployment guidance explicitly notes that the HNSW graph is not compressed. (high confidence) (verified as of 2026-10-30) [source]
- In MongoDB's AWS us-east-1 benchmark, the 5.5-million-vector dataset indexed across four dimensionalities used S50 storage-optimized nodes for scalar quantization (32 GB RAM, 843 GB disk, 4 vCPUs) and S30 high-CPU nodes for binary quantization (8 GB RAM, 213 GB disk, 4 vCPUs). This illustrates keeping CPU capacity while reducing RAM; it is a benchmark configuration rather than a universal sizing prescription. (low confidence) (verified as of 2026-10-30) [source]
- MongoDB recommends node RAM at least 10% above the vector index memory requirement to leave JVM headroom. With quantization, use the Required Memory measurement rather than treating the entire on-disk index size as resident RAM. (low confidence) (verified as of 2026-10-30) [source]
- Keeping compressed vectors in RAM and original vectors on disk is also a Qdrant design pattern. Its scalar-quantization experiments identify disk reads as a throughput constraint under restricted memory. A consolidation comparison should therefore measure storage latency and rescoring work rather than assuming that RAM savings remove the I/O budget. (medium confidence) [source]
Facts and statements
- With Atlas automatic quantization, quantized vectors occupy Search Node memory while full-precision vectors remain on disk for exact search or rescoring. RAM and disk capacity must therefore be estimated separately. (high confidence) (verified as of 2026-10-30) [source]
- For an initial Atlas RAM estimate, vector count and dimensionality determine the vector payload, but runtime memory and index structures also need headroom. MongoDB calls out JVM memory; Elastic's independent sizing example separately accounts for the HNSW graph, runtime, and active page cache. Those Elastic quantities must not be imported as Atlas constants. (medium confidence) [source]
- MongoDB positions storage-optimized Search Nodes for large indexes with moderate query and indexing loads, including binary-quantized search. Its sizing article describes fixed local SSD capacity and warns that disk growth can otherwise force excess compute provisioning; treat this as vendor workload guidance that needs testing on the actual index. (low confidence) (verified as of 2025-08-12) [source]
- Disk-rescoring capacity tests should distinguish cold reads from warm-cache execution. Elastic's July 2026 reproduction measured zero disk reads during its timed warm workload even though originals were disk-backed; Qdrant's documentation independently warns that actual disk reads during rescoring cost search speed. This scopes the benchmark evidence and does not establish Atlas-specific IOPS requirements. (medium confidence) [source]
- A defensible TCO sizing comparison must match recall, copies of the data, hardware, and query behavior. Qdrant's July 8 comparison changed quantization, hardware, and replication from Elastic's original test; Elastic's July 13 response reports near-parity for search on matched hardware after controlling ingestion layout and result-ID retrieval. These are competing vendor experiments, not an Atlas performance ranking. (medium confidence) [source]
- The mongodb-developer/vector-quantization Java repository demonstrates float, automatic scalar, automatic binary, and pre-quantized ingestion paths. It can supply a functional comparison starting point, but its README supplies no measured Search Node RAM, disk, or vCPU capacity benchmark. (low confidence) (verified as of 2026-10-30) [source]
- A RAM-fitting tier can still be CPU-constrained. MongoDB ties available CPUs to internal query concurrency, while its sizing article also identifies ingestion and indexing as CPU consumers. Size against target query throughput and latency during representative indexing activity. (high confidence) (verified as of 2026-10-30) [source]
- Storage-optimized Search Nodes target large indexes with moderate query and indexing demand; high-CPU nodes target heavier computation. Binary quantization can shift the binding resource from memory to storage, making the cheaper node class workload-dependent. (high confidence) (verified as of 2026-10-30) [source]
- Elastic's June 2026 DiskBBQ article shows that vector layout and native SIMD kernels affect scoring throughput even with quantized vectors. Its reported gains come from an M1 Max/Java 25 JMH microbenchmark with 1024-dimensional vectors; they do not establish Atlas vCPU requirements or an end-to-end cross-product speedup. (low confidence) (verified as of 2026-06-02) [source]
- Inference for TCO modeling: compare complete, tested deployment configurations at a common recall and latency target. Account separately for database nodes, dedicated Search Nodes, replication, index memory, retained originals, and CPU demand; vector compression alone does not establish a cheaper platform. (medium confidence) [source]
Children
- No children recorded.