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).
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.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Sizing embedding infrastructure starts with a single multiplication: raw storage equals the number of vectors times the dimension times the bytes per element. For 10 million 1536-dim float32 vectors, the answer is 61.44 GB. That number is the anchor every other capacity question pivots from.
The interview value here is less in the arithmetic and more in what comes after. The raw number understates production reality by a large factor because of HNSW graph overhead, payload, replication, and snapshot retention. The raw number also overstates infrastructure inflexibility because dim, dtype, and quantization are all design knobs that compose multiplicatively to shrink the footprint.
This answer walks through the calculation, the unit convention, the production-overhead story, and the four knobs that move the total.
The calculation and the unit pitfall
The formula is:
where N is the vector count, d is the dimension, and b is the bytes per element. For the scenario: N = 10,000,000, d = 1536, b = 4 (float32). Multiply through:
10,000,000 × 1536 × 4 = 61,440,000,000 bytes
The question defines 1 GB = 10^9 bytes (decimal gigabyte), so the answer is 61.44 GB. If the convention had been 1 GiB = 2^30 bytes (binary gibibyte), the same byte count would be 57.22 GiB. The 7 percent gap between the two conventions is small individually but recurs in every capacity-planning conversation, so getting the unit explicit matters.
Most cloud providers price storage in GB-months at the 10^9 convention. Linux file system tools (df, du) often report in GiB without saying so. AWS, GCP, and Azure storage docs use GB at 10^9. Always check which convention applies before quoting a number to a finance team or sizing a billing forecast.
A sanity check on the answer: 1536 float32 numbers per vector is 6,144 bytes per vector. 10 million of them is 61.44 GB. The cross-check is in the same shape as the original multiplication and catches single-digit arithmetic errors fast.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- OpenAI 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.
- Pinecone's pricing calculator uses essentially this formula plus index-overhead multipliers, so engineering on a real platform involves the same back of envelope.
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?
Double d, double the bytes: 10M × 3072 × 4 = 122.88 GB. The 2x change tracks the 2x dim change exactly because storage is linear in d.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
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.
60 second bullets to scan on the way to the call.
Can you state the raw-bytes formula for an index given N, dimension, and dtype?
How many bytes per element does each common dtype occupy?
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.