How would you plan capacity (RAM, disk, CPU, node count) for a collection of a given size, vector dimensionality, and expected QPS?

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.

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.

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.