RAG Storage Calculator
Estimate the vector database storage required for a RAG (Retrieval-Augmented Generation) pipeline.
Inputs
e.g. 1536 for OpenAI text-embedding-3-small.
Total Storage Required
0.737GB
Raw Vector Storage
0.614GB
Total Chunks
100,000
Step by step
Total chunks: documents × chunks per document
10,000 × 10
= 100,000
Vector storage: chunks × embedding dimension × bytes per float
100,000 × 1536 × 4
= 0.614 GB
Total with 20% metadata overhead: vector storage × 1.2
0.614 GB × 1.2
= 0.737 GB
How it works
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
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.