toolbox
Home / AI, Data & Technology / RAG Storage Calculator

RAG Storage Calculator

This calculator estimates storage for a retrieval-augmented generation corpus by modeling document chunking, embedding vectors, per-chunk metadata, and retained raw text. It helps translate content volume and embedding dimensions into an infrastructure estimate.

The result is most useful for early capacity planning and comparing chunk strategies. Actual database size can be higher because indexes, replicas, compression, identifiers, logs, and provider-specific overhead are not represented by the core vector calculation.

Calculator inputs

docs
words
words
words
dims
bytes
Result
—
Estimated RAG storage
Estimated chunks—
Vector data—
Metadata allowance—
Raw text estimate—

1. Enter document count
Count the records that will be ingested into the RAG collection.

2. Estimate average document length
Use words after cleaning if boilerplate will be removed.

3. Choose chunk size
Enter the target words stored in each text chunk.

4. Set chunk overlap
Overlap repeats context between adjacent chunks and increases storage.

5. Enter embedding dimensions
Use the output vector length of the selected embedding model.

6. Choose bytes per dimension
Four bytes represents float32; smaller encodings use less space.

7. Review storage components
Compare vector, metadata, and raw-text estimates before adding database overhead.

Estimated chunks per document = max(1, ceil((average words − overlap) ÷ (chunk words − overlap)))

Where:

  • Total chunks: documents × estimated chunks per document
  • Vector bytes: total chunks × embedding dimensions × bytes per dimension
  • Metadata allowance: total chunks × 1,024 bytes
  • Raw text estimate: documents × average words × 6 bytes

Assumptions: Metadata is approximated at 1 KB per chunk and raw text at 6 bytes per word. Index, replica, and provider overhead are excluded.

What the result means

Use the primary result together with the detailed breakdown. Scenario assumptions can materially change the estimate.

This planning tool does not replace provider documentation, a production benchmark, or professional advice.

Given: 100,000 documents averaging 800 words, 300-word chunks, 50-word overlap, 1,536-dimensional embeddings, and 4 bytes per dimension.

Calculation:
Stride = 300 − 50 = 250 words.
Chunks per document = ceil((800 − 50) ÷ 250) = 3.
Total chunks = 100,000 × 3 = 300,000.
Vector data = 300,000 × 1,536 × 4 = 1,843,200,000 bytes.
Metadata = 300,000 × 1,024 = 307,200,000 bytes.
Raw text = 100,000 × 800 × 6 = 480,000,000 bytes.

Result: Core storage is approximately 2.45 GB before vector-index and replication overhead.

Why must overlap be smaller than chunk size?

Otherwise the stride becomes zero or negative, so chunking cannot advance through the document.

Does vector database indexing add storage?

Yes. Index structures, replicas, write-ahead logs, and provider overhead can materially increase the deployed size.

What changes when embeddings are quantized?

Bytes per dimension decrease, reducing vector storage. Quantization may also affect retrieval quality and supported index types.

Should raw documents be stored in the vector database?

Not necessarily. Some systems store only chunk text and metadata, while others reference an external object store.

How does smaller chunk size affect storage?

It usually creates more chunks and therefore more vectors and metadata. It can improve retrieval granularity but increases cost and index size.