What are the workload dimensions of an ANN system (N, d, k, QPS)?
The workload dimensions of an approximate nearest-neighbor system are the small set of numbers that together describe how demanding a particular search workload actually is, and they’re conventionally abbreviated N, d, k, and QPS: the number of vectors in the dataset, the number of dimensions each vector has, the number of results requested per query, and the number of queries the system needs to serve per second. These four numbers don’t determine everything about how well a system like HNSW will perform, but they set the basic scale of the problem, and most of the tuning guidance found throughout this documentation is really guidance about how to respond to a particular combination of these four values.
What does each of these four dimensions actually control?
N, the size of the dataset, is the most obvious lever — it directly affects how much memory the raw vectors and the graph structure built on top of them will need, and it shapes how the graph‘s hierarchy and connectivity end up behaving, since a graph with a few thousand nodes and a graph with a billion nodes face genuinely different challenges around navigability and construction time even when built with identical parameters.
d, the ambient dimension of each vector, directly affects the cost of every individual distance computation, since computing distance between two vectors generally requires work proportional to how many coordinates each one has. It also interacts with the curse-of-dimensionality effects covered elsewhere in this documentation — a higher d doesn’t automatically make search harder, since a dataset’s effective difficulty tracks its intrinsic dimensionality more than its raw ambient dimension, but d does set a hard floor on the per-vector storage cost and the per-comparison computational cost regardless of how the data’s intrinsic structure actually behaves.
k, the number of results requested per query, affects both how much bookkeeping the search has to maintain during traversal — a larger k means a bigger result set to track via the dual-queue structure covered elsewhere in this documentation — and how wide the search generally needs to explore before its stopping criterion is satisfied, since a search asking for more results needs a correspondingly larger pool of candidates to be confident it’s found the true best k.
QPS, queries per second, describes the throughput demand a serving system needs to sustain, and it interacts with hardware and infrastructure concerns more directly than the other three dimensions — a low-QPS workload might tolerate a slower, more thorough search per query, while a high-QPS workload puts real pressure on keeping individual query latency low, since sustaining a high rate of throughput generally requires either very fast individual queries or enough parallel serving capacity to handle many queries concurrently, or some combination of both.
Why does it matter to think about these four numbers together, rather than one at a time?
The four dimensions interact with each other in ways that make a workload’s actual difficulty depend on their combination rather than any single one in isolation. A dataset with a huge N but a small d and a modest QPS requirement might be entirely comfortable to serve even with generous, accuracy-favoring parameter settings, since there’s no serious pressure on either per-query speed or per-comparison cost. The same N with a much higher d and a demanding QPS requirement is a genuinely harder problem, since every distance computation costs more and there’s less room to spend that extra cost on a slower, more thorough search without falling behind the required query rate.
This is exactly why tuning guidance throughout this documentation tends to be framed in terms of trade-offs rather than fixed recommendations — the right value for M, efConstruction, or efSearch depends heavily on where a given workload sits across all four of these dimensions simultaneously, not on any single one of them considered alone. A workload with a large N, high d, large k, and high QPS requirement is asking for a system to do a lot of expensive work, quickly, and often — exactly the combination that tends to require the most careful tuning and, in some cases, the additional machinery like quantization or sharding covered later in this documentation, to keep the whole system practical.
How do these dimensions connect to the way real benchmarks and evaluation methodology are actually structured?
Serious benchmarking of ANN methods, including HNSW, generally reports results across a range of values for these dimensions specifically because performance characteristics that hold at one point in this four-dimensional space don’t necessarily hold at another. A parameter setting that achieves excellent recall and speed on a modest, low-dimensional dataset offers no guarantee of behaving the same way on a much larger, higher-dimensional one, which is exactly why rigorous benchmark methodology, covered in more depth in the evaluation-and-benchmarking chapter of this documentation, treats N, d, k, and QPS as explicit axes to vary and report results across, rather than testing a single fixed combination and generalizing from it.
Having covered the four numbers that together set the scale of any approximate nearest-neighbor workload, the fuller treatment in the tuning-and-optimization chapter is the natural next stop, since it walks through exactly how M, efConstruction, and efSearch should be adjusted in response to different combinations of these dimensions. From there, the latency-percentile and queries-per-second glossary pages, under benchmarking and evaluation concepts, go deeper into how QPS specifically gets measured and reported in rigorous benchmark methodology.