Estimate the RAM (and disk, where the docs give it) that the vector search structures need in Elasticsearch, OpenSearch and Qdrant, side by side. Every number comes from a formula in the engine's official docs, shown with your inputs filled in.
Copies = replicas + 1
Default 16
int8 (HNSW)
Quantized options assume float source vectors. Raw vectors stay on disk for rescoring, so they count toward disk, not RAM.
Source: official docsfloat32 (no quantization)
Native (off-heap) memory for the Faiss graph. The docs give no disk formula. Replica shards are full copies, so each one is counted.
Source: official docsfloat32 (no quantization)
Payloads are cold (on disk) by default; caching them in RAM costs about base x payload x 1.5 x 3. The docs suggest about 20% headroom on top of these totals.
Source: official docs| Elasticsearch option | RAM (GiB) | Disk (GiB) |
|---|---|---|
| 77.5 | 77.5 | |
| 39.3 | 39.3 | |
| 20.3 | 20.3 | |
| 3.6 | 3.6 | |
| 20.6 | 96.9 | |
| 11 | 87.3 | |
| 3.8 | 80.1 | |
| 5.4 | 81.7 |
Smaller encodings trade some accuracy for memory. How much depends on your embeddings and queries, so measure recall on your data before you commit.
These are estimates of the vector index memory only, for all copies (primary plus replicas), in binary GiB (1 GiB = 230 bytes; some docs write "GB" for the same unit). They are not total cluster sizing: JVM heap, the OS, other fields, text indexes, segment merges and query load all need memory on top. Benchmark before you buy hardware.
Related: Elasticsearch consulting, OpenSearch consulting, Qdrant consulting and Elasticsearch vs Qdrant.
For HNSW, roughly the vector bytes plus the graph links, per vector, per copy. Elasticsearch documents N x (vector bytes + 4 x m), OpenSearch Faiss documents 1.1 x (vector bytes + 8 x m) per vector, and Qdrant documents vectors plus base x m x 2 x 4 x 1.2 for the graph. The calculator applies each formula to your numbers.
Yes. Quantized vectors are what has to stay in memory for search, while the full-precision originals can stay on disk for rescoring (Elasticsearch, and Qdrant when originals are on disk). Disk usage goes up slightly because both copies are stored. Accuracy impact depends on your data, so measure recall on your own queries.
Yes. Each replica is a full copy of the index, so the calculator multiplies by replicas + 1. Elasticsearch documents this for disk, and Qdrant counts replicas in its base point count.
No. It covers the vector search structures only. JVM heap, the operating system, other fields, text indexes, merges, payload indexes and query load all need memory too. Use the result as a floor and confirm with a benchmark on your data.
Tell us about your data, dimensions and latency targets. We will help you benchmark and size Elasticsearch, OpenSearch or Qdrant for your workload.
