# Search Node sizing and disk-to-RAM ratios for quantized vector indexes > Source-anchored research for Search Node sizing and disk-to-RAM ratios for quantized vector indexes. Run status: COMPLETED. Parent: [Atlas Vector Search automatic quantization and rescoring](https://llms-explorer.com/tree/atlas-vector-search-automatic-quantization-and-rescoring/) · 5 facets · 16 facts · page: https://llms-explorer.com/tree/search-node-sizing-and-disk-to-ram-ratios-for-quantized-vector-indexes/ ## Structure and components - Inference for consolidation TCO: compare the cost of hardware that accommodates quantized vectors, the search structure, retained originals and operating headroom at the required service level. Multiplying a memory-compression factor directly into a total-cost saving omits resources that MongoDB, Qdrant and Elastic explicitly retain. (medium confidence) — [source](https://www.mongodb.com/docs/vector-search/deployment/deployment-options.md) ## Measurements and reference values - MongoDB estimates effective vector RAM reductions of approximately 3.75x for scalar quantization and 24x for binary quantization. Its benchmark overview distinguishes these practical estimates from the 4x and 32x reductions in raw representation size; graph and other overhead prevent equivalent whole-index reductions. (medium confidence) — [source](https://www.mongodb.com/docs/vector-search/deployment/deployment-options.md) - For automatic binary quantization with rescoring, MongoDB gives the rough disk estimate original index size multiplied by 25/24: a 1 GB original becomes about 1.042 GB. The documentation explains that the HNSW graph is not compressed. This estimate concerns search-index disk storage, not source-collection storage or total deployment storage. (low confidence) — [source](https://www.mongodb.com/docs/vector-search/deployment/deployment-options.md) - MongoDB recommends allocating free disk space equal to 125% of the estimated index size for automatically quantized vectors. Treat this as the documentation's provisioning guidance; it is separate from the 25/24 binary-index estimate. (low confidence) — [source](https://www.mongodb.com/docs/vector-search/deployment/deployment-options.md) ## Problems, failure modes and limitations - Elastic reports that its repeated-query benchmark warmed original vectors into page cache and observed zero disk reads during timed throughput. Its stated limitation is that this does not measure performance when searchable structures or rescoring working sets exceed RAM. Disk-to-RAM capacity ratios alone therefore cannot establish production latency or IOPS needs. (low confidence) — [source](https://www.elastic.co/search-labs/blog/vector-search-benchmark-elasticsearch-qdrant) ## Comparisons and alternatives - Automatic quantization reduces resident vector memory while retaining original vectors on disk for refinement or exact retrieval. MongoDB and Qdrant both describe keeping quantized vectors and HNSW structures in RAM; this pattern shifts capacity requirements toward disk rather than removing the original-vector storage requirement. (high confidence) — [source](https://www.mongodb.com/docs/vector-search/deployment/deployment-options.md) - A 32x reduction in binary vector representation is not a safe whole-process RAM assumption: MongoDB uses a roughly 24x practical estimate, and Qdrant's published 100,000-vector example reports 900 MB before versus 128 MB after binary quantization. Different graph, metadata and runtime costs make headline compression factors non-transferable across engines. (medium confidence) — [source](https://www.mongodb.com/docs/vector-search/deployment/deployment-options.md) - The MongoDB developer example demonstrates automatic and pre-quantized ingestion paths and side-by-side queries, but its README does not provide a production disk-to-RAM sizing benchmark. It is an implementation lead rather than independent validation of the sizing ratios. (low confidence) — [source](https://github.com/mongodb-developer/vector-quantization) - MongoDB estimates binary index disk size with rescoring as original index size multiplied by 25/24, rather than a 32-fold disk reduction. Its explanation includes retained originals and an uncompressed HNSW graph. It separately recommends free disk space equal to 125% of estimated index size. (low confidence) — [source](https://www.mongodb.com/docs/vector-search/deployment/deployment-options.md) - In MongoDB’s June 10, 2025 implementation, float32 index disk usage was 394.73 MB, binary 407.66 MB and scalar 492.83 MB. Reported required memory was respectively 394.73 MB, 16.99 MB and 131.42 MB. These measurements support RAM savings, not smaller total index disk footprints, and are workload-specific rather than universal Search Node requirements. (low confidence) — [source](https://www.mongodb.com/company/blog/technical/scaling-vector-search-mongodb-atlas-quantization-voyage-ai-embeddings) - MongoDB’s March 5, 2025 article models estimated RAM as HNSW plus searchable vectors with a 1.1 overhead multiplier, while disk includes originals, graph and quantized copies. It explicitly says actual overhead varies. Treat this example as an illustrative resource model rather than a measured node-wide memory guarantee. (low confidence) — [source](https://www.mongodb.com/company/blog/innovation/why-vector-quantization-matters-for-ai-workloads) - Qdrant’s September 18, 2023 binary-quantization example reports 128 MB RAM for 100,000 1536-dimensional vectors versus a 900 MB unquantized estimate. Its HNSW structures still occupy RAM and originals can remain on disk. This illustrates why raw 32-to-1 vector compression is not a universal whole-system RAM saving or an Atlas sizing formula. (low confidence) — [source](https://qdrant.tech/articles/binary-quantization/) - For cross-vendor TCO, compare resident search structures, runtime overhead and active page cache consistently. Elastic’s July 13, 2026 benchmark critique warns that JVM heap allocation and total process memory are different measures; MongoDB’s resource model also separates index structures from overhead. This is a methodological inference, not a measured Atlas-versus-Elastic cost result. (medium confidence) — [source](https://www.elastic.co/search-labs/blog/vector-search-benchmark-elasticsearch-qdrant) ## Facts and statements - MongoDB documentation recommends hardware accommodating roughly 4:1 storage-to-RAM for automatic scalar quantization and 24:1 for binary quantization. These are approximate sizing guidelines, not guaranteed compression or billing ratios. The shared documentation snapshot is dated 2026-10-14. (low confidence) — [source](https://www.mongodb.com/docs/vector-search/deployment/deployment-options.md) - The MongoDB benchmark's AWS node table describes low-CPU nodes as having roughly 6:1 disk-to-memory capacity and high-CPU or storage-optimized nodes as roughly 25:1. Together with MongoDB's sizing article, this supports evaluating disk-rich classes after quantization shifts the constraint toward storage. These are source-specific profiles, not a guarantee for every cloud or tier. (medium confidence) — [source](https://www.mongodb.com/docs/vector-search/benchmark/overview.md) - Quantization can replace memory pressure with disk-access costs during rescoring. Qdrant warns about retrieving originals from disk, while Elastic's July 13, 2026 analysis shows how a repeated query set can fit the rescore working set into page cache. Capacity and latency estimates should distinguish warm-cache from cold-cache behavior. (medium confidence) — [source](https://qdrant.tech/articles/what-is-vector-quantization/)