Private RAG Corpus Sizing Calculator: Chunks, Vectors, and Storage
This free private RAG corpus sizing calculator estimates the chunk count, vector storage, text storage, and embedding compute required to index an enterprise document estate, and it is built for solution architects and infrastructure leads planning on-prem or air-gapped retrieval systems. Enter document count, page and token density, chunk size and overlap, embedding dimensions, and replication factor, and the tool returns corpus token volume, total chunks, index storage, raw text storage, and initial embedding hours. Teams routinely discover that indexing is far cheaper than expected while re-indexing after a chunking change is far more expensive.
Your numbers
Every file you intend to index: work instructions, specs, drawings text, service reports, and ERP attachments.
Manufacturing corpora skew short, but quality manuals and contracts pull the average up quickly.
A dense text page runs 500-700 tokens. Drawing sheets and forms run far lower after extraction.
Target passage length for embedding. Structure-aware chunking usually lands between 400 and 1,000.
Overlap preserves context across boundaries but multiplies chunk count and storage.
Higher dimensions can improve retrieval but scale index size and memory linearly.
Copies of the index kept for availability and query throughput.
Your results
Planning estimates only. Actual index size varies with vector compression, quantization, and index type (HNSW graphs add 20-40% overhead). Validate on a representative 1% sample before provisioning production storage.
Get your full RAG sizing and architecture plan
We will email you a personalized corpus sizing breakdown with chunking, embedding model, and index design recommendations, and a Netray AI architect will follow up on your retrieval requirements.
No spam. Your results stay private. Unsubscribe anytime.
How the sizing math works
The calculator converts documents into tokens, tokens into chunks, and chunks into stored vectors. With the defaults, 250,000 documents at six pages and 500 tokens per page gives 750 million tokens. Chunking at 512 tokens with 15% overlap means each chunk advances only about 435 tokens, producing roughly 1.72 million vectors. At 1,024 dimensions stored as float32, each vector occupies 4 KB, so a single index copy is about 6.6 GB and a two-copy production deployment is around 13 GB. Extracted chunk text adds roughly 2.8 GB. Embedding the corpus once on a single GPU at about 50,000 tokens per second takes roughly four hours.
Sizing benchmarks for manufacturing corpora
These reference points come from indexing engineering and quality documentation for aerospace, defense, and electronics manufacturers. Document estates in these environments are larger and messier than most teams estimate before they inventory them, largely because content is scattered across ERP attachments, network shares, PLM vaults, and a decade of email exports nobody has audited. Run a file inventory before trusting a document count, and sample page density rather than assuming it, since scanned drawings and forms extract to far fewer tokens per page than prose. The figures below hold up well across the manufacturing corpora we have indexed, but validate them on your own sample.
- Vector storage is rarely the constraint: a million chunks at 1,024 dimensions is under 4 GB per copy.
- HNSW and other graph index structures add 20-40% on top of raw vector size, so budget headroom.
- Overlap above 20% inflates chunk count sharply while adding little retrieval benefit for structured technical content.
- Metadata and permission attributes often consume more operational effort than the vectors themselves, because they drive access control.
Interpreting the numbers before you build
Storage is almost never the problem. The real planning constraints are embedding throughput during initial load, the cost of re-indexing when you change chunking or embedding models, and the query-time memory required to hold the index hot. If embedding compute returns more than about twenty-four hours, plan a parallel load across multiple GPUs or a staged rollout by document class. Also decide your re-index strategy up front: changing embedding models invalidates every existing vector, so a corpus that takes four hours to build today takes four hours again every time you upgrade. Teams that ignore this end up frozen on a model they chose in week one.
How Netray builds private retrieval systems
Netray builds RAG systems over manufacturing content that general-purpose tools handle poorly: revision-controlled work instructions, engineering specifications, supplier certifications, non-conformance reports, and decades of ERP transaction history in SyteLine, LN, or M3. We chunk on document structure rather than fixed character counts, carry ERP and PLM entitlements into the retrieval layer so users only see what they are authorized to see, and run the entire pipeline inside your network for ITAR and CMMC-constrained customers. Engagements typically start by indexing a representative subset and measuring retrieval quality against a golden question set before scaling to the full corpus.
Frequently Asked Questions
How much does chunk overlap really cost me?
More than most teams expect, because it multiplies chunk count directly. Moving from zero to fifteen percent overlap raises chunk count by about eighteen percent, and thirty percent overlap raises it by roughly forty-three percent. That flows straight into storage, embedding compute, and query-time memory. For structured technical content with clean section boundaries, ten to fifteen percent is usually sufficient. Reserve higher overlap for continuous narrative prose where meaning genuinely spans boundaries.
Do I need high-dimensional embeddings for technical documents?
Usually not. Domain-specific technical vocabulary is quite separable, and 768 or 1,024 dimension open models frequently match 1,536 or 3,072 dimension alternatives on manufacturing corpora while using a third of the memory. The bigger quality lever is fine-tuning or selecting an embedding model that understands your part numbering, standards references, and abbreviations. Test two or three candidates on a labeled retrieval set before defaulting to the largest available option.
How should I plan for re-indexing?
Assume you will re-index at least twice in the first year, because chunking strategy and embedding model choice both improve as you learn from real queries. Keep extracted text separate from vectors so re-embedding does not require re-parsing source documents, which is usually the slowest step. Build the pipeline to run incrementally by document class so you can re-index a segment and compare retrieval quality before committing the whole corpus.
Get a sized retrieval architecture with chunking strategy, index design, and a phased indexing plan for your document estate.
Related Tools
Model Context Window Planner
Allocate a fixed context window across system prompt, retrieved chunks, conversation history, and reserved output, then see exactly how much retrieval headroom is left.
On-Prem AILLM Token Cost Calculator
Turn request volume, prompt length, and per-million token pricing into a defensible monthly and annual LLM budget, including the effect of prompt caching.
On-Prem AIGPU Cluster Utilization Calculator
Turn GPU capital, amortization, and operating cost into an effective cost per productive GPU hour, and find the utilization threshold where owning beats renting.
Go Deeper
On-Prem LLM Deployment Architecture: Reference Guide
Reference architecture for on-prem LLM deployment: inference servers, GPU sizing, RAG pipelines, and security zones for regulated manufacturers.
Air-Gapped LLM Deployment Patterns That Actually Work
Air-gapped LLM deployment patterns that work: offline model transfer, update workflows, monitoring without telemetry, and CMMC-ready architectures.