You have 1,000,000 documents. Each is embedded as a 768-dimensional float32 vector. Compute the raw storage required (vectors only). Express in GB (1 GB = 10^9 bytes).
**The answer is 3.072 GB.** Storage for a corpus of float32 vectors equals the number of vectors times the dimension times 4 bytes per element.
- N = 1,000,000 documents
- d = 768 dimensions per vector
- bytes per element = 4 (float32)
Multiply: 1,000,000 × 768 × 4 = 3,072,000,000 bytes. Divide by 10^9 to get 3.072 GB.
The mental anchor matters more than the exact number. A million 768-dim float32 vectors fits in a few GB of RAM on a developer laptop, which is why this is the canonical 'small index' size in tutorials and prototypes. You can load the whole thing into memory and run brute-force search at sub-millisecond per query.
Scaling up linearly: 10 million docs at the same dim is 30.72 GB (still fits on a single machine's RAM with care), 100 million is 307 GB (now you need a distributed setup or aggressive quantization), 1 billion is 3.07 TB (definitely distributed). The 768-dim float32 size is a useful unit for back of envelope sizing.
**3.072 GB.** The calculation is a single multiplication. Bytes = N × d × 4 = 1,000,000 × 768 × 4 = 3,072,000,000 bytes = 3.072 GB at the 10^9 convention.
This is raw vector storage. Production reality runs higher because of three independent overheads.
- **HNSW graph edges** add 2-4x the raw footprint depending on the M parameter. A real HNSW index of these vectors lands closer to 10-15 GB on disk.
- **Payload** (document IDs, source URLs, timestamps) is independent of d and typically adds 100 bytes to 1 KB per vector. For a million docs at 500 bytes per payload, that is 0.5 GB.
- Replication for HA multiplies the total by your replica count, usually 2-3x.
A million-doc index is the canonical 'small index' size. The raw 3 GB fits in laptop RAM, brute-force search is sub-millisecond per query, and you can prototype the whole system on a single machine. The arithmetic scales linearly, so 10M docs is 30.72 GB raw, 100M is 307 GB, 1B is 3.07 TB. Each order of magnitude on N moves you to a different infrastructure regime.
The broader knobs to reduce the raw number (Matryoshka truncation, float16 dtype, int8 scalar quantization, binary quantization) compose multiplicatively. For a million-doc index they rarely matter because storage is not the bottleneck; for a billion-doc index they often determine whether the system is buildable at all.
Quick reference
TL;DR
1M × 768 × 4 bytes = 3.072 GB. A million 768-dim float32 vectors fits comfortably in a few GB of RAM and is the canonical 'small index' size.
Picture a million flashcards, and each one has 768 numbers written on it in tiny print. Each number takes about 4 bytes to store. Multiply the cards by the numbers per card by the bytes per number, and you have your total. That comes out to a little over 3 gigabytes, roughly the size of a single high-definition movie. A million-doc index at this scale fits in the RAM of a normal developer laptop, which is why this is the canonical 'small index' size in tutorials. Scaling up to a hundred million flashcards turns that movie into a whole streaming library, and you start needing more serious infrastructure.
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 production budget rather than back of envelope Add index overhead, payload, replication, and snapshot retention. The raw formula is the floor, not the quote.
Your vectors use a non-uniform dtype (e.g., quantized index where centroids and assignments have different widths) PQ and other learned-quantization schemes have storage formulas that involve codebook size and assignment width, not just N × d × bytes_per_float.
Your index sharding scheme stores per-shard metadata that grows non-linearly with N Sharded indexes can add bookkeeping that does not follow the simple N × d × bytes_per_float formula; size each shard separately.
Quick scan · 2–4 min
Everything important, quickly.
Compute 3.072 GB via N × d × 4, identify the small-index regime, walk the order of magnitude scaling, and close on when storage stops being a free design choice.
Real-world examples
Real products, models, and research that use this idea.
1BGE-base, MiniLM, and Snowflake Arctic Embed M all produce 768-dim vectors; a million docs at these models is the prototype scale where teams skip HNSW entirely and brute-force on a laptop.
2Pinecone's free tier comfortably hosts million-doc 768-dim indexes precisely because the raw storage sits around 3 GB.
3OpenAI text-embedding-3-small at d=1536 doubles this number to 6.14 GB for the same million-doc corpus: the kind of comparison that comes up in model-choice sizing.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhat's the same calculation for OpenAI text-embedding-3-small at d=1536?
Sign in or go Pro to see the approach for this follow-up.
QHow does the answer change if you store as int8 instead of float32?
Sign in or go Pro to see the approach for this follow-up.
QWalk through the order of magnitude scaling up to 1B docs.
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
Calling this number 'production storage'. It is raw vector storage only; HNSW overhead, payload, and replication can push the realized footprint 5-10x higher.