Capacity planning has four components that must be estimated separately: vector storage, index overhead, payload and metadata, and compute. Vector storage is the simplest: points times dimensions times bytes_per_dimension, where bytes_per_dimension is 4 for float32, 1 for int8, and 1/8 for binary. For 10M points at 768 dimensions: 30.7 GB for float32, 7.7 GB for int8, and 0.96 GB for binary. Index overhead is the HNSW graph: roughly points times 2 times m times id_bytes on layer 0, plus 10-30 percent for upper layers. For 10M points at m=16 and 4-byte IDs, that is about 1.3-1.7 GB. Payload and metadata include the payload fields, the payload indexes, the point IDs, and internal bookkeeping; for a collection with several indexed fields, this can be a meaningful fraction of the total. Compute is the number of cores needed to serve the QPS at the latency target: each query costs a number of distance computations proportional to ef and the graph traversal, and each core can serve a bounded number of queries per second. Node count follows from the total footprint divided by the per-node capacity, with headroom for peaks, replication, and failover.

The mechanism that determines the node count is the balance between the memory footprint and the per-node capacity. A node can hold a certain amount of data in RAM and on disk, and it can serve a certain number of queries per second given its CPU. The number of nodes is the maximum of the memory-driven count and the compute-driven count. For an in-memory collection, the memory count is total RAM footprint divided by usable RAM per node, and the compute count is QPS times latency_budget divided by cores_per_query. For an on-disk collection with quantization, the memory count drops dramatically because only the quantized vectors and the hot portion of the graph need to be resident; the disk count becomes relevant instead. Replication multiplies the storage cost: with replication_factor=2, you need twice as many nodes (or twice the storage per node) to hold the replicas. Headroom matters: plan for at least 20-30 percent headroom for the optimizer, the OS, and burst traffic. The exact numbers depend on the workload, so a capacity plan should be validated with a benchmark on the target hardware.

1
Vector storage: points x dims x bytes_per_dim, where bytes_per_dim is 4 (float32), 1 (int8), or 1/8 (binary).
2
HNSW graph: points x 2 x m x id_bytes on layer 0, plus 10-30 percent for upper layers.
3
Payload and indexes: depends on the number and cardinality of indexed fields; often 5-20 percent of total.
4
Quantized vectors in RAM: the compressed vectors that are always resident for traversal.
5
Compute: cores needed to serve QPS at the latency target; depends on ef and the graph traversal cost.
6
Replication: multiplies storage and compute by the replication factor.
7
Headroom: 20-30 percent for the optimizer, OS, and burst traffic.
8
Node count: max(memory-driven, compute-driven) x replication factor, rounded up.

The trade-off is between cost and headroom. A tight plan minimizes hardware cost but leaves no room for peaks and failover; a generous plan costs more but is more robust. The right balance depends on the workload's variability and the cost of an outage. The common mistakes are: (1) counting only the raw vector bytes and forgetting the graph and indexes; (2) assuming that an on-disk collection needs no RAM at all; (3) not accounting for the optimizer's temporary memory usage during merges; (4) not planning for replication in the node count; (5) assuming that the benchmark's QPS is achievable at production latency without measuring under load. Version note: the memory overhead of the graph and the payload indexes depends on the internal implementation and has changed across Qdrant releases. Measure the actual RSS of a representative collection on your version rather than relying on a fixed formula.

javascript

Version-dependent: the memory overhead of the graph and the payload indexes varies by version. On-disk HNSW and inline storage change the memory calculus. Benchmark a representative collection on your version before committing to a capacity plan, and re-check after upgrades.

Difficulty: 8/10

Topics: Capacity Planning, Memory Optimization, Scaling

Scenario Questions

0-2 years experience

1
You size a node for 10M vectors by counting vector bytes and it runs out of RAM. Explain what you forgot and how to redo the estimate.
2
A teammate says on-disk collections need no RAM. Explain what still needs to be resident and why.

2-5 years experience

1
You need to plan a deployment for 50M vectors with a 20ms p99 and a budget. Describe the components of the plan and how you would validate them.
2
Your benchmark shows that the compute-driven node count is higher than the memory-driven count. Explain what this means and how you would tune the workload.

5-8 years experience

1
Design a capacity plan for a multi-tenant collection with 100M points, a 30ms p99, and a replication factor of 3. Specify the node size and count.
2
You need to reduce the infrastructure cost by 40 percent without dropping below the latency SLO. Describe the levers and the impact of each.

8+ years experience

1
Derive a capacity model that takes point count, dimensionality, m, quantization, QPS, and latency target as inputs, and outputs node size and count. Where does the model break down?
2
You are designing a capacity planning tool for a fleet of Qdrant clusters. Describe the model, the inputs, and how you validate it against production telemetry.

Follow-up Questions

❓How would you validate the capacity plan with a benchmark on the target hardware before provisioning?
❓If the compute-driven node count exceeds the memory-driven node count, what does that tell you about the workload, and what would you tune?