How Much Vector Storage Does One Million Home Document Chunks Require?
One million chunks need roughly 1.5–6.1GB for common float32 vectors alone, before graph indexes, metadata, text, replicas, and working space.
The arithmetic starts with dimensions, not document count: one million 768-dimensional float32 vectors contain 768 million four-byte values, or about 3.07 GB decimal. A deployable store is larger because it must identify vectors, search them efficiently, filter metadata, retain chunk text, and survive index maintenance during both search and maintenance operations on the server.
Raw Vector Bytes Provide the Reproducible Floor
Multiply chunk count by embedding dimensions and bytes per coordinate. For one million float32 vectors, 384 dimensions use 1.536 GB, 768 use 3.072 GB, and 1,536 use 6.144 GB. Binary gigabytes appear about seven percent smaller in displayed units.
A scaling overview gives the same raw vector storage relationship: dimension count multiplied by value width determines the coordinate payload before database structures.
Float16 can halve the vector component, and int8 or product quantization can reduce it further. Compression may affect recall and requires database support. The source documents and generated chunk text are not included in these numbers.
Indexes and Metadata Can Rival the Coordinates
Flat search adds relatively little index structure but scans many vectors. HNSW stores neighbor links and multiple graph layers to reduce search work. Per-vector IDs, deleted-record tombstones, filters, alignment, and database pages add further overhead.
An introduction to HNSW connectivity describes why graph connectivity accelerates approximate search while consuming extra memory and storage. The configured neighbor count directly changes that cost.
Metadata varies even more. A compact document ID and language code may add tens of bytes; repeated paths, permissions, and full chunk text can add hundreds or thousands. Store text once or inside the vector database consistently before comparing totals.
Where a Single Storage Estimate Fails
A practical planning range for one million 768-dimensional float32 chunks is often 5–12 GB for vectors plus an approximate index, before substantial text and replicas. This is a budgeting range, not a format guarantee.
A vector architecture comparison estimates HNSW storage overhead that substantially exceeds raw coordinates for some HNSW configurations. Engine defaults and graph parameters determine the real multiplier.
The range fails with multiple embeddings per chunk, hybrid keyword indexes, replication, snapshots, or rebuilds that temporarily duplicate data. It can also overstate a compressed disk-backed store. “One million chunks” is insufficient unless dimension, dtype, index, metadata, and copy count are named.
Extrapolate From a Ten-Percent Index Sample
Insert 100,000 representative chunks using the final embedding dtype, metadata schema, and index parameters. Measure raw vector column, index, metadata, text, write-ahead log, and snapshot bytes separately after compaction. Extrapolate scalable components by ten and add rebuild plus backup headroom.
Place the test on the intended storage working space storage tier because compression and filesystem allocation affect physical totals. Avoid extrapolating from empty database files.
Budget at least the measured steady total plus one temporary index copy and 20 percent free space. If replication is enabled, multiply only replicated components. Repeat the sample whenever dimensions, metadata, or HNSW neighbor settings change.
Recommended products
Tech & AI HUB
More to Read
How to Measure Local RAG Retrieval Quality and Interpret Recall, Precision, and Citation Coverage
Build a local RAG test set, calculate core retrieval metrics, interpret their tradeoffs, and audit whether answer claims are supported by cited evidence.
Why Does Smart Home Feature Computation Matter More as Sensor Count Increases at the Same Sampling Rate?
Trace per-sensor and cross-sensor compute as device count rises, identify nonlinear fusion costs, and benchmark the feature pipeline before automations lag.
Why Does RAG Evaluation Cost Matter More as the Document Library Grows at the Same Query Volume?
Understand why corpus growth raises RAG evaluation effort without more user queries and how stratified tests keep cost tied to risk.
