Every embedding is a list of numbers, and a vector database stores millions of them plus an index to search them quickly. Before choosing a database plan or server size, you need to know how big that gets. This calculator estimates raw vector size, index overhead, metadata and replicas, and shows how much quantization can save.
How it works
Raw vector size is vectors × dimensions × bytes per dimension. A 1,536-dimension float32 vector is 1,536 × 4 = 6,144 bytes, so 10 million of them are about 61 GB before any index.
An HNSW index stores a graph of neighbours for fast approximate search. Its bottom layer keeps up to 2 × M links per vector, stored as 4-byte IDs, so at M = 16 that's about 128 bytes per vector plus a little for the upper layers. IVF indexes add much less but usually need tuning to reach good recall. A flat index adds nothing and searches exactly, but is slow at scale.
Quantization shrinks vectors. float16 halves the size, int8 quarters it, and binary quantization cuts it to 1/32. Recall drops somewhat with each step, so many systems keep compressed vectors in memory and re-rank the top results using full-precision copies on disk.
Metadata and replicas multiply everything. Storing the original chunk text alongside each vector can easily outweigh the vectors themselves. Each replica stores a full copy. Real databases also add their own overhead, so treat these results as a planning estimate and leave headroom of 20–50%.
A worked example
10 million OpenAI-size embeddings (1,536 dimensions, float32) take 61.44 GB as raw vectors. An HNSW index at M = 16 adds about 1.34 GB, and 200 bytes of metadata each adds 2 GB, for 64.78 GB per copy. With 2 replicas you need about 129.57 GB. Switching to int8 cuts the raw vectors to 15.36 GB.
Questions people ask
How much storage do embeddings need?
Multiply the number of vectors by the dimensions and by 4 bytes for float32. One million 768-dimension vectors need about 3.07 GB; one million 3,072-dimension vectors need about 12.29 GB, before index and metadata.
How much memory does an HNSW index use?
Roughly M × 2 × 4 bytes per vector for the graph links, plus the vectors themselves if they're kept in memory, which most HNSW implementations do for speed. The vectors usually dominate: the graph is small by comparison unless M is large.
Does quantization hurt search quality?
Somewhat. int8 usually keeps recall close to full precision. Binary quantization loses more, so it's typically used for a fast first pass, with the top candidates re-scored using full vectors. Test on your own queries before switching.
Should I pick fewer dimensions to save space?
It can help a lot. Some embedding models let you shorten vectors with only a small loss in quality. Halving dimensions halves vector storage and speeds up search. Compare retrieval quality on your own data first.
Why is my database bigger than this estimate?
Databases add their own overhead: write-ahead logs, deleted records waiting for cleanup, segment files, and payload indexes on metadata fields. Budget extra headroom on top of this estimate.