Vector Storage Cost Calculator
Vectors × dimensions × bytes per component, plus the HNSW graph and the metadata, into gigabytes and a monthly bill.
18.7 GB across 2 copies. The graph is 7.1% of every vector.
- Vector data per vector
- 1,536 B
- Full-precision rescoring copy
- 0 B
- HNSW graph (33 links × 4 B)
- 132 B
- Metadata
- 200 B
- Total per vector
- 1,868 B
- One copy
- 9.340 GB
- Stored (× 2)
- 18.7 GB
- Monthly
- $4.67
- Annual
- $56.04
- Same index at float32
- 64.8 GB — $16.19 / mo
- Saved by quantising
- 71.2%
The number most vector storage estimates produce is vectors × dimensions × 4 bytes, and it is too low by between a fifth and several multiples. Two terms are missing from it. The first is the index: an HNSW graph stores neighbour ids per node, and at the common M of 16 that is 33 links, or 132 bytes, on every vector regardless of how small you have made the vector itself. Quantise 1536 dimensions from float32 to int8 and the vector drops from 6,144 bytes to 1,536 — at which point the graph you were ignoring is closer to a tenth of the total than to the fiftieth it was, and a 4× compression of the vectors delivers well under a 4× saving on the bill.
The second is that quantisation is rarely used alone. The standard pattern searches the small vectors and then re-ranks the top few hundred candidates against the originals, which means keeping the originals — and the float32 copy is larger than everything else on the page combined. Turning that switch on above is the difference between a 75% saving and a 5% one.
What this does not price: query compute, which for an in-memory index is the dominant cost and scales with traffic rather than with size; the build itself, which needs materially more memory than the finished index; and the backup or snapshot copies your provider may charge for separately. If you are choosing between a managed vector database and a Postgres extension, note that this arithmetic is identical for both — what differs is the rate per GB-month and whether it is memory or disk.