Compute storage for 1M docs at 768 dim, float32
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).
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.
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.
A million 768-dim float32 vectors is the canonical small-index size in retrieval engineering. It is small enough to fit in laptop RAM, fast enough to brute-force search in sub-millisecond, and large enough to look like a real workload. The arithmetic that produces 3.072 GB is trivial, but the mental anchors that come out of it are useful for the entire range of capacity-planning conversations.
The calculation is N × d × bytes_per_float = 1M × 768 × 4 = 3,072,000,000 bytes = 3.072 GB at the 10^9 GB convention. That number plays a useful role in your head: it is the unit cell of embedding storage at the small end of production scales, and the linear scaling story carries it up to 100x and 1000x deployments with predictable consequences.
This answer walks through the calculation, the small-index regime it characterizes, and the order of magnitude scaling up to billion-doc indexes.
The calculation and the unit anchor
The formula is the standard one:
where N is the vector count, d is the dimension, and b is the bytes per element. For the scenario: N = 1,000,000, d = 768, b = 4 (float32). Multiply through:
1,000,000 × 768 × 4 = 3,072,000,000 bytes
Divide by 10^9 (per the question's GB definition) to get 3.072 GB. The cross-check is in per-vector terms: 768 float32 numbers per vector is 3,072 bytes per vector, and a million of them is 3.072 GB.
Unit conventions matter. The question explicitly defines 1 GB as 10^9 bytes (the decimal gigabyte used in cloud pricing and disk-manufacturer marketing). The binary equivalent, 1 GiB = 2^30 bytes, would give 2.86 GiB for the same byte count. The 7 percent gap is small individually but shows up consistently in cross-team conversations between engineering (often binary) and finance (decimal). Always state the convention.
A mental anchor worth keeping: 3 KB per vector at 768-dim float32. That number scales linearly with d and with vector count. For 1536-dim float32 it is 6 KB per vector; for 384-dim float32 it is 1.5 KB. The per-vector size is the unit that does the most work in back of envelope sizing conversations.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- BGE-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.
- Pinecone's free tier comfortably hosts million-doc 768-dim indexes precisely because the raw storage sits around 3 GB.
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?
Double d, double the bytes: 1M × 1536 × 4 = 6.144 GB. The 2x change tracks the 2x dim change exactly.
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.
Calling this number 'production storage'. It is raw vector storage only; HNSW overhead, payload, and replication can push the realized footprint 5-10x higher.
60 second bullets to scan on the way to the call.
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.