You're sizing infrastructure for an embedding index. The corpus has 10,000,000 documents. You're using text-embedding-3-small at its native dimension of 1536, stored as float32. Compute the raw vector storage required (vectors only, no index overhead, no metadata). Express the answer in GB (1 GB = 10^9 bytes).
**The answer is 61.44 GB.** The formula is simple: raw vector storage equals the number of vectors times the dimension times the bytes per element.
- N = 10,000,000 documents
- d = 1536 dimensions per vector
- bytes per element = 4 (float32 uses 4 bytes per number)
Multiply them together: 10,000,000 × 1536 × 4 = 61,440,000,000 bytes. Divide by 10^9 (the question defines 1 GB = 10^9 bytes) to get 61.44 GB.
That is the raw vector storage. Three things shift the total in production.
- **HNSW graph edges** add roughly 2-4x the raw vector footprint, so a real HNSW index of these vectors might land closer to 150-250 GB on disk.
- **Quantization** can reduce per-element storage by 4-32x. Switching to int8 cuts each number to 1 byte (4x savings); binary quantization gives 1 bit per dim (32x savings).
- Replication for high availability multiplies the total by your shard replica count, typically 2-3x.
The mental anchor: doubling d doubles both storage and per-query compute. That is why dim choice is a load-bearing decision in retrieval system design.
**61.44 GB.** The calculation is a single multiplication:
$$\text{bytes} = N \cdot d \cdot 4 = 10{,}000{,}000 \times 1536 \times 4 = 61{,}440{,}000{,}000 \text{ bytes}$$
Divide by 10^9 (per the question's definition) to convert: 61.44 GB.
This is raw vector storage. The production total runs higher because of three independent factors. HNSW graph edges add roughly 2-4x the raw vector footprint depending on the M parameter; for a tuned production index, total disk usage can land in the 150-250 GB range. IVF adds smaller cluster-centroid storage. Metadata payloads (document IDs, timestamps, source URLs) are independent of d and add a fixed overhead per vector.
Four design moves can shrink the raw number from this baseline.
- **Truncate the dim** via Matryoshka (3072 to 1536 to 768, etc.); savings are linear.
- **Switch to float16 or bfloat16** for a 2x savings with negligible quality cost on most models.
- Scalar quantize to int8 for a 4x savings with under 1 recall@10 point cost on well-trained models.
- Binary quantize for a 32x savings with 5-10 recall@10 points cost; pairs well with a reranking step.
The broader mental model: raw vector storage = N × d × bytes_per_element. Each factor is a design knob. Picking the right d, dtype, and quantization is the production-economics half of embedding system design.
Quick reference
TL;DR
10M × 1536 × 4 bytes = 61.44 GB raw vector storage; index overhead and quantization shift the total but the raw number is the anchor.
Picture a giant spreadsheet with 10 million rows and 1,536 columns, where every cell holds one decimal number that takes 4 bytes of space. The total size of the spreadsheet is just the count of cells multiplied by the size of each cell. Multiply 10 million by 1,536 to get the cell count, then multiply by 4 bytes per cell, and you have your total in bytes. Divide by a billion to get gigabytes. The answer falls out cleanly: 61.44 GB. The rest of the work (adding index overhead, picking a smaller dim, switching to a smaller number format) is layered on top of this one straight multiplication.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
You need a precise infrastructure budget rather than a back of envelope estimate Production sizing also needs index-overhead multipliers, payload sizing, replication factor, and snapshot retention. The raw formula is a starting point, not a quote.
Your vectors are not all the same dimension or dtype Mixed-dim or mixed-dtype indexes need per-shard calculations; a single multiplication oversimplifies.
Your index uses quantization that changes bytes per dim non-linearly (e.g., PQ codebooks) PQ replaces per-dim floats with codebook indices, so the storage math involves codebook size and assignment width rather than the raw N × d formula.
Quick scan · 2–4 min
Everything important, quickly.
Compute 61.44 GB explicitly via N × d × 4, distinguish GB from GiB, walk through what the raw number excludes (HNSW overhead, payload, replication), and close on the four design knobs to shrink it.
Real-world examples
Real products, models, and research that use this idea.
1OpenAI text-embedding-3-small at native 1536 dim is the canonical 'small but capable' default; at 10M docs it really does need around 60 GB of raw storage and 150-250 GB of HNSW index space.
2Pinecone's pricing calculator uses essentially this formula plus index-overhead multipliers, so engineering on a real platform involves the same back of envelope.
3Self-hosted Qdrant and Weaviate clusters at 10M-100M scale routinely report total disk usage 3-5x the raw vector number after HNSW overhead and replication.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QCompute the same number for the OpenAI text-embedding-3-large at native dim 3072. How does the answer change?
Sign in or go Pro to see the approach for this follow-up.
QIf you switch from float32 to int8 quantization, what does the storage become and what's the typical recall cost?
Sign in or go Pro to see the approach for this follow-up.
QWalk through a back of envelope total for a production HNSW index of these vectors at 3x replication.
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Mixing up GB and GiB (10^9 vs 2^30 bytes) and getting a 7% off answer. The question specifies 10^9 explicitly; honor it.