Embedding Storage Calculator
How much storage a vector index needs — from document count, chunk size and embedding dimensions — plus the cost of generating the embeddings.
A vector is dimensions times bytes per dimension: a 1,536-dimension embedding at 32-bit floats is 6 KB.
How the embedding storage calculator works
A vector is dimensions times bytes per dimension: a 1,536-dimension embedding at 32-bit floats is 6 KB. Multiply by the number of chunks and add the index overhead, which for an approximate-nearest-neighbour index is substantial — often as much again as the vectors themselves.
The lever most people miss is dimension reduction and quantisation. Storing vectors as 8-bit integers cuts storage fourfold with very little retrieval quality lost, which at scale is the difference between fitting in memory and not.
Formula: storage = chunks × dimensions × bytes × (1 + index overhead)
Worked examples
| Inputs | Total storage | Note |
|---|---|---|
| 50,000 documents at 1,536 dimensions | 5.65 GB | about 5 GB |
| Smaller embeddings | 1.41 GB | a quarter of the storage |
| No index overhead | 2.82 GB | vectors only |
FAQFrequently asked questions
How big is an embedding?
Dimensions times bytes. A 1,536-dimension vector at 32-bit floats is 6 KB; at 8-bit it is 1.5 KB.
Why does the index cost as much as the vectors?
Because approximate-nearest-neighbour structures store graph links or cluster assignments alongside the data. Doubling is a reasonable planning figure.
Should I quantise?
Usually yes. 8-bit costs very little retrieval quality and cuts storage fourfold, which often decides whether the index fits in memory.
What chunk size should I use?
Two hundred to 800 tokens for most retrieval. Smaller chunks retrieve more precisely; larger ones carry more context per hit.
Why does overlap matter?
It stops an answer being split across a chunk boundary, at the cost of more chunks. Ten to twenty per cent is the usual compromise.
Where these figures come from
- Vaswani et al. (2017) — Attention Is All You Need — the transformer architecture the memory arithmetic follows
- Kaplan et al. (2020) — Scaling Laws for Neural Language Models — the compute relationship used for training estimates
- Hoffmann et al. (2022) — Training Compute-Optimal Large Language Models — the tokens-per-parameter guidance ("Chinchilla")
- IEEE 754 — Standard for Floating-Point Arithmetic — the numeric formats behind bytes per parameter
- National AI Centre — Australia's national AI body
Last checked: September 2026. The relationships here are architectural, not vendor-specific: bytes per parameter follow the numeric format, KV-cache size follows the transformer definition, and token-per-word ratios come from published tokeniser behaviour.