Estimate total storage requirements for a retrieval-augmented generation pipeline.
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.
total_storage = documents * chunks_per_doc * embedding_dim * bytes_per_float * 1.2
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.
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.
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.
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.