# Vector index memory sizing and quantization trade-offs on Search Nodes > Source-anchored research for Vector index memory sizing and quantization trade-offs on Search Nodes. 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/) · 4 facets · 16 facts · page: https://llms-explorer.com/tree/vector-index-memory-sizing-and-quantization-trade-offs-on-search-nodes/ ## How it works - MongoDB explicitly identifies binary-quantized vector search as a workload in which the bottleneck can move from RAM to storage. Its Search Node sizing article recommends evaluating SSD index capacity, ingestion and indexing demand, query throughput, and latency when selecting a node class. Inference for TCO: smaller required memory alone does not establish which node tier is cheapest. (medium confidence) — [source](https://www.mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) - Changing Atlas quantization settings triggers an index rebuild. MongoDB's Java example also warns that changing quantization rebuilds the index. A capacity plan should account for rebuild work when comparing operating costs; these sources do not quantify peak rebuild memory or temporary disk amplification. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/vector-search/about/vector-quantization.md) - Rescoring can recover quality but adds work against original vectors; its latency effect depends on storage and cache behavior. Elastic reports quality recovery through rescoring, while Qdrant's disk-constrained experiments show a throughput advantage when rescoring is disabled at the cost of precision. Neither experiment determines Atlas latency. (medium confidence) — [source](https://www.elastic.co/search-labs/blog/evaluating-scalar-quantization) ## Measurements and reference values - The cached Atlas deployment guide proposes roughly 4:1 storage:RAM for scalar and 24:1 for binary quantization, and approximates binary index disk size with retained originals as original index size × 25/24. It separately recommends free disk space equal to 125% of estimated index size. These are vendor planning recommendations, not universal compression laws or a substitute for measured capacity. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/vector-search/deployment/deployment-options.md) - Elastic's May 3, 2024 evaluation found average relative nDCG@10 decreases of 0.83% for multilingual E5-small and 0.59% for E5-base after int8 index quantization. This is model- and benchmark-specific evidence of quality loss, not an Atlas result or proof that quantization preserves accuracy universally. (low confidence) — [source](https://www.elastic.co/search-labs/blog/evaluating-scalar-quantization) - For float32 vectors, N × dimensions × 4 bytes estimates vector payload only; graph and runtime overhead require additional capacity. Qdrant's published 1.5× payload rule includes its graph allowance and must not be substituted as an Atlas sizing constant. (medium confidence) — [source](https://www.mongodb.com/docs/vector-search/deployment/deployment-options.md) ## Comparisons and alternatives - MongoDB's documentation distinguishes vector-value compression (4× scalar; 32× binary) from approximately 3.75× and 24× reductions after accounting for an HNSW graph that remains uncompressed. Treat these as documented sizing approximations rather than guaranteed whole-node RAM or bill reductions. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/vector-search/deployment/deployment-options.md) - Retaining original vectors for rescoring creates a memory-versus-I/O trade-off, not free compression. Atlas reads original floats for binary rescoring; Qdrant independently reports that disk reads dominated throughput in a memory-constrained scalar-quantization experiment. The Qdrant result supports the mechanism, not an Atlas latency forecast. (medium confidence) — [source](https://www.mongodb.com/docs/vector-search/about/vector-quantization.md) - In Qdrant's published slow-network-disk experiment with a 2 GB memory limit, throughput was 2 RPS without scalar quantization, 30 RPS with scalar quantization and rescoring, and 1200 RPS without rescoring; reported precision was 0.99, 0.989, and 0.974 respectively. The article says the original 2023 settings were not recorded, so these rows illustrate a trade-off rather than a portable capacity estimate. (low confidence) — [source](https://qdrant.tech/articles/scalar-quantization/) - A MongoDB Community discussion documents an operator confusing overall stored data with vector-index memory requirements; the response distinguishes collection size from vector-search index size. Together with the separate Atlas Size and Required Memory metrics, this supports measuring the actual search index rather than using collection bytes as the memory budget. (medium confidence) — [source](https://www.mongodb.com/community/forums/t/want-to-know-the-exact-relation-between-size-of-vector-db-stored-in-mongodb-and-the-constant-ram-usage-associated-with-it/290899) ## Facts and statements - In the cached Atlas documentation, the Size metric includes graph, compressed vectors and retained originals, whereas Required Memory estimates the index's query-time memory. A quantized index can appear larger on disk while requiring less RAM; node sizing should distinguish these metrics. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/vector-search/deployment/deployment-options.md) - Quantization does not guarantee unchanged search quality. MongoDB recommends scalar quantization for lower-dimensional models that are not quantization-aware-trained; Elastic measured small retrieval-quality losses with int8 indexing and mitigated them through rescoring. These findings support workload-specific quality validation before claiming infrastructure savings. (medium confidence) — [source](https://www.mongodb.com/docs/vector-search/about/vector-quantization.md) - Quantized search can retain original full-precision vectors for rescoring while keeping compressed vectors resident. MongoDB, Elastic and Qdrant each describe this arrangement; reduced resident-vector memory therefore does not imply equivalent reduction in total persistent storage. (high confidence) — [source](https://www.mongodb.com/docs/vector-search/deployment/deployment-options.md) - MongoDB's August 12, 2025 sizing article identifies binary-quantized vector search as a storage-constrained use case for storage-optimized Search Nodes. Its reasoning is consistent with the deployment guide's retained-originals accounting: after RAM compression, fixed local SSD capacity can determine the required tier. (medium confidence) — [source](https://www.mongodb.com/company/blog/technical/the-art-and-science-of-sizing-search-nodes) - Fitting the index into RAM alone does not establish a sufficient node configuration. MongoDB recommends allowing for JVM memory and available CPUs, while its sizing article also identifies ingestion, indexing, disk I/O, query throughput and latency as capacity constraints. TCO sizing should validate these constraints at the intended workload. (medium confidence) — [source](https://www.mongodb.com/docs/vector-search/deployment/deployment-options.md) - For consolidation TCO, quantization belongs in both the Atlas and separate-engine configurations: Elastic and Qdrant also document compressed-vector search with retained originals. Inference: crediting compression savings only to Atlas would confound a broadly available representation choice with the economics of platform consolidation. (medium confidence) — [source](https://www.mongodb.com/docs/vector-search/deployment/deployment-options.md)