Vector Index Sizing
Works out how much RAM a vector index needs from its vector count, dimensions, precision and graph width — and how many nodes that is.
3,910 bytes per vector. Fits one 32 GiB node, using 11.4% of it.
- Raw vectors — count × dims × bytes
- 2.86 GiB
- Neighbour lists — count × links × 4 bytes
- 122.1 MiB
- Payload and ids
- 190.7 MiB
- Subtotal
- 3.17 GiB
- Times overhead factor 1.15
- 3.64 GiB
- Bytes per vector, all in
- 3,910 bytes
- Vectors that fit one node
- 8,787,657
- Shards at that node size
- 1
What the number covers, and what it leaves out
Three terms decide how much memory a vector index occupies, and only the first one is obvious. The vectors themselves are exactly count × dimensions × bytes-per-component, which is why moving from fp32 to int8 cuts the largest term by four with no change to anything else. The second term is the graph: an HNSW index stores a neighbour list per vector, and at the usual layer-0 width of 2 × M that is 32 four-byte ids, or 128 bytes per vector, before you have stored a single dimension. On a 128-dimension binary index the graph is bigger than the data. The third term is the payload, which people forget entirely and which a chatty metadata schema can make dominant.
The overhead factor is not padding for its own sake. Vector stores rarely compact on delete; they tombstone, and a collection that has been rewritten a few times carries dead rows until it is rebuilt. Any allocator also rounds. Fifteen per cent is a starting point, not a measurement — raise it if your corpus churns.
What this does not model: replicas, the query-time working set, the build-time spike (constructing a graph transiently needs more than serving it), or the separate copy of the chunk text most systems keep so they can return something readable. Size the box for the peak, not for this number.