You have 10M documents embedded as 3072-dim float32 vectors. You truncate to 768 dimensions using Matryoshka. Compute the savings in storage (express as a ratio: original storage / truncated storage).
**The answer is 4x.** Storage cost for a corpus of N float32 vectors at dimension d is exactly N × d × 4 bytes. Both N and the float dtype stay constant in this scenario, so the ratio reduces to:
3072 / 768 = 4
You get exactly four times less storage. Concretely, 10M docs at 3072-dim float32 take 122.88 GB; the same 10M at 768-dim float32 take 30.72 GB. The 92 GB saved is real and immediately visible in your infrastructure bill.
The ratio is exact because there is no hidden per-vector overhead that changes with dimension: the vector storage is just a flat array of 32-bit floats per vector. Index overhead (HNSW graph edges, IVF cluster IDs, payload metadata) does add fixed cost, but that part is independent of d, so the dim-driven savings are clean.
The quality cost for a well-trained Matryoshka model at a 4x truncation is typically under 5 recall@10 points, often in the 1-3 point range. That cost-quality trade is why Matryoshka has become a default for production retrieval: 4x cheaper storage and proportionally faster search for a single-digit quality cost is a strong deal.
**4x.** Storage scales linearly with embedding dimension when the float dtype and vector count are fixed:
$$\text{bytes} = N \cdot d \cdot \text{bytes\_per\_float}$$
In this scenario N = 10M, dtype = float32 (4 bytes), and d shrinks from 3072 to 768. Plug in.
- Original: 10,000,000 × 3072 × 4 = 122,880,000,000 bytes = 122.88 GB
- Truncated: 10,000,000 × 768 × 4 = 30,720,000,000 bytes = 30.72 GB
- Ratio: 122.88 / 30.72 = 4
The 4x savings are exact, not approximate. Search compute on a dot-product or HNSW kernel also scales linearly with d, so the same 4x ratio applies to query latency and memory bandwidth at search time.
The quality cost depends on the model and corpus. Well-trained Matryoshka models (OpenAI text-embedding-3-large, Nomic Embed v1.5, Snowflake Arctic Embed L 2.0) report 1-3 recall@10 points lost at a 4x truncation on standard benchmarks. The exact number for your workload requires a sweep against your own eval set, but a single-digit cost for 4x storage savings is the typical regime.
This is the underlying economics that make Matryoshka a default for production retrieval. Storage cost drops 4x, compute cost drops 4x, quality cost stays small.
Quick reference
TL;DR
Storage is linear in dimension, so 3072 → 768 gives 3072/768 = 4x savings. The recall cost for a well-trained Matryoshka model is typically under 5 recall@10 points.
Picture a row of identical lockers, each holding one filled-out form. If you shrink each locker to one quarter its old size, you fit four times as many lockers in the same room. That is the whole calculation. The arithmetic is just three thousand seventy two divided by seven hundred sixty eight, which equals four, because shelf space is a straight count of numbers written on each form. You cut the count of numbers per form by four. No hidden factors, no extra overhead. The interesting question is what you lose by shrinking the locker. For a form designed to be safely chopped short, the answer is surprisingly little, usually a small dip in search quality, not a collapse.
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.
Your embedding model is not Matryoshka-trained Slicing a non-Matryoshka model destroys the geometry; you get the storage savings but lose far more than 5 recall@10 points.
Storage cost is already negligible for your corpus size If raw vector storage is a small line item compared to compute or operational cost, the 4x save is not worth the quality cost.
Your quality floor cannot tolerate even 1-3 recall@10 points of loss High-precision regimes (medical, legal) often have hard recall floors that require the full dim regardless of storage cost.
Quick scan · 2–4 min
Everything important, quickly.
Compute the 4x ratio explicitly, decompose total storage into raw plus index overhead, note the sub-linear HNSW latency story, and close on the typical quality cost.
Real-world examples
Real products, models, and research that use this idea.
1OpenAI text-embedding-3-large at 3072 dim costs 4x as much to store as the same model truncated to 768 via the `dimensions` parameter; this is the headline benefit OpenAI advertises.
2Nomic Embed v1.5 release notes report 1-2 recall@10 points lost at 4x truncation on broad-domain benchmarks, validating the cost-quality trade.
3Snowflake Arctic Embed L 2.0 production case studies show enterprise customers cutting storage by 4x via Matryoshka truncation while maintaining production recall targets.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QIf you also quantize from float32 to int8, what's the combined storage savings ratio?
Sign in or go Pro to see the approach for this follow-up.
QHow does the savings ratio change on disk versus in RAM versus in network transit?
Sign in or go Pro to see the approach for this follow-up.
QIf your eval shows >5% recall@10 loss at 4x truncation, what does that suggest about the model or corpus?
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
Forgetting that storage savings are exact, not approximate, when both the float dtype and the vector count stay the same. The only variable is dimension.