What the Vector Database Storage Calculator does
This calculator estimates how much storage a vector database needs: the raw embeddings, IDs, metadata, the index structure (HNSW graph, IVF centroids or product-quantisation codes), a storage overhead and every replica - and projects how that total grows month by month. Every assumption is listed under the result and every input can be changed.
It is for sizing a first deployment, comparing float32 with float16, int8 or binary quantisation, or checking whether an index will still fit in memory next year. It is arithmetic in your browser, not a benchmark of any particular product.
How to use it
- Enter how many vectors you will store, their dimensions (your embedding model's output size) and the precision you store them at.
- Estimate the average metadata per vector. If you store the chunk text alongside the vector, this is often larger than the vector itself.
- Pick the index type. For HNSW set M, the number of links per node; for IVF set the number of lists; for IVF-PQ also the number of one-byte sub-quantisers.
- Set an overhead percentage for your engine's fragmentation, write-ahead log and segment files, and the number of extra replicas.
- Add a monthly growth rate to see the projection, then copy the summary or download the breakdown as CSV.
Reading the results
The headline is the total across all copies. The per-copy figure is what one node or shard group has to hold; for engines that keep the index in memory, that is roughly the RAM you need before query working space.
The breakdown shows what dominates. At high dimensions the vectors themselves usually do, which is why quantisation gives the biggest savings. With small vectors and rich payloads, metadata can be the largest part.
Treat the result as a planning estimate. Real engines add their own headers, alignment, deleted-but-not-compacted rows and caches; compare against a real test load before buying hardware.
Worked example: 1 million RAG chunks with 1,536-dimension embeddings
One million chunks embedded at 1,536 dimensions in float32 take 1,536 x 4 = 6,144 bytes each, 6.144 billion bytes in total. Add 8-byte IDs (8 MB), 500 bytes of metadata each (500 MB) and an HNSW graph at M = 16, which the hnswlib layout puts at 136.5 bytes per vector (about 137 MB).
That is 6.79 billion bytes before overhead; with 20% overhead one copy needs 8.15 billion bytes, 7.59 GiB. With one replica the total is 15.17 GiB. At 5% monthly growth there are 1,795,856 vectors after 12 months and the total reaches 27.25 GiB.
Switching the vectors to float16 cuts the total to 8.31 GiB; int8 to 4.87 GiB. Neither changes metadata or graph size, which is why the savings are less than a straight half or quarter.
Formulas and scoring rules
- Raw vectors
N x d x bytes per componentfloat32 4, float16/bfloat16 2, int8 1; binary uses ceil(d / 8) bytes per vector.- HNSW links per vector
(2M + 1) x 4 + (M + 1) x 4 / (M - 1)hnswlib layout: 2M neighbours on layer 0 with a count, plus the expected upper layers (a vector reaches layer l with probability M^-l).- IVF centroids
nlist x d x 4- IVF-PQ
codes = N x m; codebooks = 256 x d x 4m one-byte sub-quantisers; d must divide by m.- Per copy and total
per copy = (vectors + ids + metadata + index) x (1 + overhead); total = per copy x (1 + replicas)- Growth
N(t) = N x (1 + g)^tMonthly compounding; vector counts rounded to whole vectors. Sizes shown in binary GiB (2^30 bytes).
Where the savings are
Quantisation shrinks the largest part. float16 halves vector storage with almost no recall loss for most text embeddings; int8 scalar quantisation quarters it; binary quantisation reduces it 32-fold but usually needs re-ranking against full-precision vectors, which you then have to keep somewhere.
Product quantisation goes further: each vector becomes m bytes. At 96 bytes instead of 3,072 for a 768-dimension float32 vector, a hundred million vectors fit in about 10 GB rather than 300 GB - at a cost in recall that you have to measure. Dimension reduction offered by some embedding models (shortened outputs) saves in the same proportion as the dimensions.
Limitations: what the result does not prove
- Engines lay data out differently. pgvector, Qdrant, Milvus, Weaviate, Pinecone and OpenSearch each add their own headers, page structure and caches, so the overhead percentage is yours to calibrate.
- It does not estimate query memory, CPU, recall or latency - only storage.
- HNSW figures follow hnswlib's graph layout. Engines that store links as 8-byte ids or keep extra layers will be larger.
- Managed services often bill by pods, read units or dimensions rather than bytes; convert with the provider's own pricing page.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- hnswlib - graph memory layout
- Malkov and Yashunin - HNSW paper
- FAISS - index types and memory
- pgvector - storage and indexing
Frequently asked questions
How much storage do 1 million embeddings need?
At 1,536 dimensions in float32, the vectors alone are 6.144 billion bytes, about 5.7 GiB. Add IDs, metadata, the index graph and engine overhead - typically another 20 to 40 percent - and multiply by the number of copies you run.
How much memory does an HNSW index use?
The vectors plus the graph. In hnswlib each vector stores up to 2M neighbour ids of 4 bytes on the base layer, plus a small expected amount for upper layers - about 136 bytes per vector at M = 16 and 264 bytes at M = 32.
Does float16 halve my vector database size?
It halves the vector part, which is usually the largest, but metadata, IDs and the index graph stay the same size. For a typical RAG index the total drops by 40 to 45 percent rather than a full 50.
How do I estimate pgvector table size?
A vector column stores 4 bytes per dimension plus a small header, and an HNSW index adds its graph on top. Enter your row count and dimensions, put your other columns into metadata, and use a higher overhead, around 30 percent, for PostgreSQL page and tuple headers.
What does the overhead percentage cover?
Everything the formulas do not: storage engine headers, alignment padding, write-ahead logs, deleted rows waiting for compaction, segment merges and free space. It varies widely by engine, so measure a sample load and adjust it.
Should replicas count towards storage?
Yes. Each replica holds a full copy of the data and usually of the index too, so storage and memory scale with the number of copies. Shards split the data but do not reduce the total.
Last reviewed by the A2Z.Tools team against the sources listed above.
