What Is Product Quantization (PQ) and How Does It Compress Vectors?

Product quantization (PQ) is a technique for compressing high-dimensional vectors by splitting each vector into smaller segments, replacing each segment with the ID of its closest match from a small, pre-trained set of representative values, and storing only those IDs instead of the original numbers. It’s a lossy compression method, meaning you permanently lose some precision, but it typically shrinks a vector’s memory footprint by more than 20x while keeping search results close enough to correct for most practical purposes — which is exactly the trade-off that makes searching over hundreds of millions or billions of vectors in memory feasible in the first place.

The Problem PQ Exists to Solve

A single vector embedding, in its raw form, is just an array of floating-point numbers — commonly hundreds or over a thousand of them, each taking 4 bytes. A collection of a million such vectors at 768 dimensions each needs roughly 3 gigabytes just to hold the raw numbers, before any index structure is even built on top of them. At tens or hundreds of millions of vectors, which is a completely ordinary scale for production search systems, storing every vector at full precision in memory becomes prohibitively expensive, and the cost scales linearly with how much data you add.

The obvious fix — store vectors in a smaller, approximate form — creates an immediate problem: you still need to calculate distances between vectors accurately enough that the ranking of nearest neighbors doesn’t fall apart. Naively rounding or truncating numbers can throw away exactly the fine-grained differences that made two vectors distinguishable in the first place. Product quantization was designed specifically to compress vectors aggressively while preserving enough of that fine-grained structure that distance comparisons still work well enough to be useful.

How Product Quantization Actually Works

The technique gets its name from how it treats a vector: not as one indivisible block of numbers, but as a product — a concatenation — of several smaller sub-vectors, called segments or subspaces. A 768-dimension vector, for instance, might be split into 96 segments of 8 dimensions each. Splitting the vector this way is what allows PQ to compress each smaller piece independently rather than trying to compress the entire high-dimensional vector at once, which is a much harder compression problem.

Once the vectors are segmented, PQ needs a way to represent each segment compactly. This is done through a training step: for each of the segments, a clustering algorithm (commonly k-means) is run across that segment’s values from a large sample of your actual data, producing a fixed number of cluster centers — typically 256 of them per segment, so each center can be identified with a single byte. This set of centers is called a codebook. Once the codebook exists, compressing a new vector is simple: for each segment, find the closest of the 256 centroids and store just that centroid’s ID — one byte — instead of the original 8 floating-point numbers for that segment.

The compression math makes the payoff concrete. A 768-dimension vector stored as 32-bit floats takes 768 × 4 = 3,072 bytes. Compressed with PQ into, say, 128 segments, that same vector takes roughly 128 × 1 = 128 bytes — about 24 times smaller, with only a small amount of extra overhead for the shared codebook itself. That ratio is the entire reason PQ exists: turning a memory requirement that scales in the gigabytes into one that scales in a fraction of that, for the exact same number of vectors.

Why This Is Lossy — and What That Actually Costs You

PQ is a lossy compression technique, and it’s worth being precise about what gets lost. Once a segment is replaced by a centroid ID, every original vector segment that happened to be closest to that same centroid becomes indistinguishable from every other one — they all get compressed to the exact same code. Two vectors that were subtly different before compression can end up mapped to identical codes, which means the compressed representation can no longer tell them apart. This is the source of what’s usually called quantization error: the small, unavoidable distortion introduced by replacing a precise value with the nearest of only 256 pre-defined options, repeated across every segment of every vector.

In practice, this shows up as a recall trade-off: search over PQ-compressed vectors returns results that are usually very close to what you’d get with full-precision vectors, but not always identical, and occasionally a true nearest neighbor gets missed because quantization blurred a real distinction that mattered. The number of segments you choose directly controls this trade-off — more segments (smaller sub-vectors per segment) preserve more distinguishing detail and cost more memory; fewer segments compress harder and lose more precision. There’s no setting that avoids the trade-off entirely; there’s only where along that curve you choose to sit.

PQ vs. Other Compression Approaches

Product quantization is one of several vector compression techniques, and it’s not automatically the right choice for every situation:

• Scalar quantization compresses each dimension of a vector independently and directly — typically from a 32-bit float down to 8 bits — without splitting the vector into segments or clustering across dimensions jointly. It’s simpler and faster to train than PQ, but because it treats each dimension in isolation, it generally can’t capture correlations between dimensions the way PQ’s per-segment clustering can, which is part of why PQ often achieves a better compression-to-recall trade-off at the cost of a more expensive training step.
• Product quantization is not the same thing as PCA (principal component analysis) or other dimensionality-reduction techniques, even though both are sometimes reached for to make vectors smaller. PCA reduces the number of dimensions a vector has, projecting it into a lower-dimensional space. PQ keeps the original dimensionality’s information intact conceptually, but represents groups of dimensions using a small shared vocabulary of learned codes rather than reducing how many dimensions exist. The two techniques can, in principle, be combined — reducing dimensionality first and then quantizing what remains — but they’re solving different parts of the compression problem, not competing solutions to the same one.
• Binary and rotational quantization represent a more extreme compression point, reducing each dimension to as little as a single bit rather than the 8-bit-per-segment codes PQ typically uses. These can compress even further than PQ, but usually need a distinct final “rescoring” step using the full-precision vectors to recover acceptable recall, since compressing that aggressively discards much more fine-grained structure.

Why PQ Is Almost Always Paired With Another Index

Product quantization on its own is a compression scheme, not a search algorithm — it doesn’t tell you which vectors to compare against, only how to represent each one cheaply once you’ve decided to compare it. In practice, PQ is combined with a separate structure that narrows down candidates before distance calculations even happen, most commonly in one of two combinations:

• IVF-PQ (Inverted File index with Product Quantization) first partitions the entire vector collection into clusters using a coarse quantizer, so a query only needs to be compared against vectors in the nearest handful of clusters rather than the entire collection — and within those clusters, PQ-compressed vectors are used for the actual distance comparisons, keeping both the search space and the memory footprint small.
• HNSW+PQ combines PQ compression with a graph-based index (HNSW) instead of cluster partitioning: the graph structure decides which nodes to visit during a search, and PQ-compressed vectors keep the memory cost of storing that graph’s vectors low, with distances during traversal calculated directly against the compressed representations.

A common refinement to either combination is a rescoring step: perform the fast, approximate search using cheap, PQ-compressed vectors first, then fetch full-precision vectors for just the shortlist of top candidates and recompute exact distances before returning final results. This recovers most of the recall that pure PQ search would otherwise lose, while paying the cost of full-precision distance calculations for only a small fraction of the total collection rather than all of it.

Where Product Quantization Came From

The technique originates from a 2011 paper by Hervé Jégou, Matthijs Douze, and Cordelia Schmid, which introduced product quantization specifically for approximate nearest neighbor search at scale, building on earlier general vector quantization theory. The core contribution was exactly the segmentation-plus-independent-clustering approach described above — a way to get vector quantization’s compression benefits without needing an impossibly large codebook trained jointly across an entire high-dimensional vector at once, which becomes intractable well before you reach the dimensionalities modern embedding models actually produce.

Implementing PQ in a Vector Database

In practice, you rarely implement product quantization by hand — vector databases that support it handle the segmentation, codebook training, and compressed distance calculations internally, and simply expose it as an index configuration option. Here’s what enabling it looks like in Weaviate:

from weaviate.classes.config import Configure, Property, DataType

client.collections.create(
    name="Articles",
    properties=[
        Property(name="title", data_type=DataType.TEXT),
        Property(name="content", data_type=DataType.TEXT),
    ],
    vector_config=Configure.Vectors.text2vec_weaviate(
        source_properties=["title", "content"],
        vector_index_config=Configure.VectorIndex.hnsw(
            quantizer=Configure.VectorIndex.Quantizer.pq(
                segments=128,          # number of segments the vector is split into
                training_limit=100000, # how many objects to use to train the codebook
            ),
        ),
    ),
)

PQ requires a training step before it can compress anything, since the codebook has to be learned from a representative sample of your actual vectors — an index configured this way typically loads data uncompressed first, trains the codebook once enough representative vectors are present, and then compresses vectors going forward (and retroactively compresses what was already loaded). The `segments` value is the main lever you control directly: more segments trade memory savings for higher recall, fewer segments trade recall for a smaller footprint, and the right setting depends on how much precision loss your particular application can tolerate.

When Product Quantization Is the Right Tool

PQ earns its place specifically when the size of your vector collection is large enough that keeping every vector at full precision in memory is itself the bottleneck — tens of millions of vectors and up is the range where this typically starts to bind. Below that scale, the memory savings often aren’t necessary, and skipping compression entirely avoids both the training complexity and the recall trade-off altogether. Above it, PQ (usually combined with IVF or HNSW, and often with a rescoring step) is one of the most well-established ways to keep large-scale similarity search both fast and affordable, at the cost of a small, controllable, and well-understood amount of precision.