RAG Storage Calculator
Estimate total storage requirements for a retrieval-augmented generation pipeline.
About RAG Storage Calculator
A RAG vector database stores one embedding vector per document chunk: vector_storage = documents × chunks_per_doc × embedding_dimension × bytes_per_float. On top of the raw vectors, production vector stores add overhead for metadata (source document IDs, chunk text, timestamps), indexing structures (e.g. HNSW graph links), and replication — approximated here as a flat 20% addition. Larger embedding dimensions and finer chunking (more chunks per document) both increase storage roughly linearly, so this is a key sizing input when choosing an embedding model and chunking strategy for a production RAG system.
Formula
total_storage = documents * chunks_per_doc * embedding_dim * bytes_per_float * 1.2
- documents
- Number of documents in the corpus
- chunks_per_doc
- Average chunks per document
- embedding_dim
- Embedding vector dimensionality
- bytes_per_float
- Bytes per float (4 for FP32, 2 for FP16)
- 1.2
- 20% overhead for metadata and indexing
Worked example
With the default values below, RAG Storage Calculator returns Total Storage Required of 0.737. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Document Countaccepts 1–1,000,000,000 docs
- 10,000 docs
- Avg. Chunks per Documentaccepts 1–100,000 chunks
- 10 chunks
- Embedding Dimensionaccepts 1–100,000 dims
- 1,536 dims
- Bytes per Floatone of FP32 (4 bytes), FP16 (2 bytes)
- FP32 (4 bytes)
Results
- Total Storage Required
- 0.737 GB
- Raw Vector Storage
- 0.614 GB
- Total Chunks
- 100,000
Step by step
- 1Total chunks: documents × chunks per document= 100,000
- 2Vector storage: chunks × embedding dimension × bytes per float= 0.614 GB
- 3Total with 20% metadata overhead: vector storage × 1.2= 0.737 GB
Assumptions and limits
- The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 3 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
Why add 20% metadata overhead?
Vector databases store more than raw floating-point vectors — they also index each vector (e.g. HNSW graph edges), store associated metadata like source text and document IDs, and often maintain small per-record overhead for filtering, all of which typically adds roughly 15-30% on top of raw vector storage.
How much does embedding dimension matter?
Storage scales linearly with dimension, so a 3072-dimension embedding model (e.g. text-embedding-3-large) requires exactly twice the vector storage of a 1536-dimension model for the same chunk count.
Should I use FP16 to save storage?
Some vector databases support storing embeddings in FP16 or with scalar/product quantization to roughly halve or further reduce storage at a small cost to retrieval accuracy — check whether your vector store and embedding model combination supports this before committing to it in production.
How does chunk size affect total storage?
Smaller chunks mean more chunks per document (more vectors to store) but better retrieval granularity, while larger chunks reduce vector count but each retrieval brings back more (potentially less relevant) text — see the Chunk Size Calculator to balance this trade-off.