Embedding Storage Size Calculator
Work out how much disk or RAM a set of embeddings needs from the vector count, dimensionality and numeric precision, including index overhead.
How it works
Raw bytes = vectors × dimensions × bytes/dimension · Total = raw × (1 + index overhead%)
An embedding is just an array of numbers, so its footprint is vectors × dimensions × the bytes each number takes. float32 uses 4 bytes per dimension; quantizing to float16 or int8 halves or quarters that with only a small accuracy loss, which is the single biggest storage lever. On top of the raw vectors, an approximate-nearest-neighbour index (HNSW, IVF) adds graph links and metadata — often 10–50% more — so budget for that overhead when planning RAM, since serving latency depends on keeping the index in memory.
Worked example
One million 1536-dimension vectors in float32 need 1,000,000 × 1536 × 4 = 6.14 GB raw. Each vector is 1536 × 4 = 6.0 KB. A 20% index overhead brings the total to about 7.37 GB.
Frequently asked questions
Should I store in float32 or quantize?
float32 is the safe default, but int8 quantization cuts storage 4× with typically a 1–3% recall drop — often a great trade for large collections. Test recall on your own queries before committing to aggressive quantization.
Does the index really need that much extra space?
Graph-based indexes like HNSW store multiple neighbour links per vector, which can add 10–50% on top of the raw data. Flat (brute-force) indexes add almost nothing but are slow at scale. Enter an overhead that matches your index type.
Is this disk or RAM?
For fast similarity search the index and vectors usually need to live in RAM, so treat this total as your memory budget. Some databases keep vectors on disk and only the index in RAM, which changes the split.
Related calculators
Educational estimate — real costs and memory depend on your provider, framework, model architecture and pricing, which change often. Verify against your own bills and profiling before committing budget.