Match each embedding storage reduction technique to its compression ratio and quality cost

Match pairs·Hard·4.0 · 0·~2 min·Asked atNeptune Ai Perplexity Vernacular Ai·Relevant atElastic Hugging Face Neo4j Qdrant

Attempt it

Drag each answer to line up with its matching prompt

Matryoshka truncation (3072 → 768)

4× storage savings, <1% recall@10 loss on most models, near free at query time

Scalar quantization (float32 → int8)

32× storage savings, 5-10% recall@10 loss on well trained models, Hamming distance at query

Binary quantization (float32 → 1 bit per dim)

4× storage savings, ~1-3% recall@10 loss, linear in truncation ratio

Product Quantization (PQ, 8 subquantizers)

8-32× storage savings, 3-8% recall@10 loss, asymmetric distance tables at query

**Four techniques, four different trades.** The match exists because each technique compresses embeddings in a structurally different way. The consequences for storage, query mechanics, and quality are different in each case. **Matryoshka truncation** cuts the dimension count. Going from 3072 to 768 is a 4x storage saving because storage is linear in dim. Quality cost on well-trained Matryoshka models is typically 1-3 recall@10 points. Query mechanics are unchanged. The truncated vector lives in the same coordinate system as the full vector, and you still use cosine or dot-product distance. **Scalar quantization to int8** shrinks each number from 4 bytes (float32) to 1 byte (int8). That gives 4x savings without changing dimension. Quality cost is under 1 recall@10 point on most modern embedding models, because int8 preserves most of the float32 precision that matters for retrieval. Query mechanics are near-identical to float32. **Binary quantization** shrinks each number to a single bit: positive or negative sign. That gives 32x raw savings. Quality cost is larger, 5-10 recall@10 points on its own. The query metric changes too: distance becomes Hamming distance (count of differing bits), which is extremely fast on modern CPUs. Product Quantization (PQ) chunks the vector into subvectors, builds a learned codebook of representative subvectors for each chunk, and stores only the codebook IDs. Storage savings depend on subquantizer count and codebook size; 8 subquantizers with 256-entry codebooks gives roughly 8-32x raw savings. Quality cost is 3-8 recall@10 points. Query distance uses precomputed lookup tables, which is fast but trickier to implement.

**The four techniques cleave into two axes**: what they reduce (dim count vs bytes per dim) and how the query distance changes. **Matryoshka truncation (4x, ~1-3 point loss, linear).** Cuts dim count at deploy time via a slice. Storage and compute both scale linearly with dim, so 3072→768 is exactly 4x. Quality cost is typically 1-3 recall@10 points on well-trained Matryoshka models. Query mechanics are unchanged: same coordinate system, same distance metric. **Scalar quantization to int8 (4x, <1 point loss, near-free).** Compresses each float32 element to int8 via a learned per-dim min-max scale. Storage drops 4x without touching dim count. Quality cost is sub-1 recall@10 point on modern models because int8 preserves the precision that matters for retrieval. Query latency is comparable to float32 with SIMD kernels. **Binary quantization (32x, 5-10 point loss, Hamming distance).** Reduces each dim to a single bit: the sign. Storage drops 32x. Quality cost on its own is large enough that binary is usually paired with a reranker on top-k candidates using full-precision vectors. The query metric becomes Hamming distance (XOR plus popcount), orders of magnitude faster than float dot product on CPU. Product Quantization (PQ, 8-32x, 3-8 point loss, lookup tables). Splits the vector into M subvectors (typically 8 or 16), learns a codebook of K centroids per subvector (typically K=256), and stores each subvector as an 8-bit codebook ID. Query distance uses asymmetric distance computation with precomputed tables: fast, but more complex to implement. They stack. Matryoshka reduces dim; the three quantizations reduce bytes per dim. Matryoshka + int8 (16x), Matryoshka + binary + rerank (128x), and IVF-PQ + Matryoshka are common in billion-scale indexes.

TL;DR

Matryoshka 4x linear, scalar quant 4x near-free, binary quant 32x with 5-10 point recall drop and Hamming distance, PQ 8-32x with asymmetric distance tables and 3-8 point loss.

Memory aid

Easy to grasp

Picture four different ways to fit too many clothes into one suitcase. The first trick is taking out half your outfits and leaving them home. Same kind of clothes, just fewer of them. The second trick is rolling each shirt tightly instead of folding it flat. Same shirts, packed denser. The third trick is replacing every shirt with a tiny black and white sketch of it on an index card. Massive space savings, but you lost color and texture. The fourth trick is photographing each outfit and stashing only the photo along with a recipe card explaining how to recreate the look. Clever, complex, big savings. Each trick gives you a different amount of suitcase room for a different amount of lost detail.

Key concepts

Embeddings Vector Databases

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.

The four storage-reduction techniques on the table (Matryoshka truncation, scalar quantization, binary quantization, and Product Quantization) solve the same surface problem (shrink the embedding index) but do it through structurally different mechanisms. The matching exercise is a test of whether a candidate has internalized those mechanisms or is operating from a vague 'these are all compression' impression.

The cleanest organizing axis is what each technique reduces. Matryoshka reduces the count of dimensions while leaving the bytes per dim unchanged. The three quantization techniques reduce bytes per dim while leaving the dim count unchanged. This is why they stack multiplicatively in production: they operate on independent axes of the vector storage equation N × d × bytes_per_dim.

This answer walks through each technique's mechanism, storage ratio, quality cost, and query-time implications, then closes on the stacking story that production billion-scale indexes use.

Matryoshka truncation: reduce the dimension count

Matryoshka representation learning trains an embedding model with a multi-prefix loss so that every leading prefix of the output vector is a valid embedding. At deploy time, truncation is a slice. Going from 3072 to 768 keeps the first 768 of the 3072 dimensions and discards the rest.

Storage savings are exact: 3072 / 768 = 4x. Compute on brute-force or IVF-flat indexes scales the same way. On HNSW, per-comparison cost is linear in d but graph traversal is not, so query latency drops sub-linearly, typically 2.5-3x for a 4x dim cut.

Quality cost on well-trained Matryoshka models is 1-3 recall@10 points at 4x truncation. The number is workload-specific; multilingual corpora and code retrieval tend toward the high end of the range.

Query mechanics are unchanged. The truncated vector lives in the same coordinate system as the full vector, so the distance metric (cosine, dot product) is the same. There is no special kernel, no lookup table, no codebook. This makes Matryoshka the lowest-complexity reduction technique and a default for any new index built on a Matryoshka-trained model.

The technique requires a Matryoshka-trained model. Slicing a non-Matryoshka embedding destroys the geometry and recall collapses. OpenAI text-embedding-3-small and 3-large, Nomic Embed v1.5, Snowflake Arctic Embed L 2.0, and several Voyage AI models support it in 2026.

Scalar quantization to int8: reduce bytes per dim

Binary quantization: reduce to 1 bit per dim with Hamming distance

Product Quantization: subvector codebooks with ADC

How they compose: the production stacking story

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Technique	Storage savings	Quality cost (recall@10)	Query mechanics
Matryoshka truncation (3072→768)	4x	1-3 points	Same as float; slice the vector
Scalar quantization (float32→int8)	4x	<1 point	Dequantize or int8 SIMD
Binary quantization (float32→1 bit)	32x	5-10 points	Hamming distance (XOR + popcount)
Product Quantization (8-16 subq)	8-32x	3-8 points	Asymmetric distance tables (lookup)

Real products, models, and research that use this idea.

OpenAI text-embedding-3-large supports Matryoshka via the `dimensions` parameter; production deployments routinely pair it with int8 quantization downstream in Qdrant or Weaviate for 16x total savings.
Faiss IVF-PQ is the canonical billion-scale index implementation; Meta uses it across its embedding-based retrieval systems, with 16 subquantizers and 256-entry codebooks typical.

What an interviewer would ask next. Try answering before peeking at the approach.

QWalk through a billion-scale production stack that combines two or more of these.

Typical: Matryoshka truncation 3072→768 (4x) + IVF-PQ with 16 subquantizers and 256-entry codebooks (16x) = 64x raw storage savings. Pair with a reranker on top-k=100 using full-precision vectors to recover most of the quality. This is roughly the pattern used at Meta and Google for web-scale retrieval.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Confusing Matryoshka with scalar quantization. They both give 4x savings at small quality cost, but one reduces dim count and the other reduces bytes per dim. They stack.

60 second bullets to scan on the way to the call.

Which technique reduces dim count vs bytes per dim
Storage savings ratio for each

Primary sources. Browse if you want the original framing.