Qdrant offers scalar, product, and binary quantization — what does each trade?

## The shape of the feature Quantization in Qdrant is a *storage and distance-computation* optimization layered onto an existing collection. The original float32 vectors are still kept; the quantized copy is an additional, much smaller representation used to traverse the HNSW graph quickly. Because the originals survive, Qdrant can re-rank the approximate candidates using exact distances — the mechanism that makes aggressive compression usable at all. You attach it at creation: `client.create_collection(collection_name="docs", vectors_config=models.VectorParams(size=1536, distance=models.Distance.COSINE), quantization_config=models.BinaryQuantization(binary=models.BinaryQuantizationConfig(always_ram=True)))` or later with `client.update_collection(collection_name="docs", quantization_config=...)`, which makes the optimizer rebuild segments in the background. You never call a separate training step; codebooks and ranges are computed by the optimizer as segments are built. ## Scalar quantization `ScalarQuantizationConfig` currently supports `type=models.ScalarType.INT8`. Every float32 component is mapped linearly onto one signed byte, so the vector shrinks about 4x. Two knobs matter. `quantile` (for example 0.99) decides the value range that maps onto the int8 scale. Embedding components are usually near-Gaussian with a few extreme outliers; if the range is set by those outliers, the entire useful middle is squeezed into a handful of levels. Clipping at the 99th percentile sacrifices fidelity for rare extremes and buys resolution where the mass of the distribution actually lives. `always_ram=True` pins the quantized vectors in memory. This is what turns quantization into a RAM strategy: the 4x-smaller copy stays resident and serves traversal, while the originals can be pushed to disk. Accuracy loss is typically small — often under one percent recall for common text embeddings — which is why scalar is the recommended starting point. Speed also improves, because int8 distance computation is cheaper and far more cache-friendly than float32. ## Product quantization `ProductQuantizationConfig` takes a `compression` value from `models.CompressionRatio`: X4, X8, X16, X32, X64. Vectors are split into subvectors, each replaced by an index into a learned codebook, so the stored form is a handful of bytes regardless of the original dimensionality. The trade is sharper than with scalar. Distances become genuinely approximate — neighbourhood structure survives, exact ordering does not — and index building is markedly slower because codebooks must be computed. In exchange, memory drops by an order of magnitude or more, which can be the difference between a collection fitting in RAM and not. Use it when memory is the binding constraint, the collection is large, and you have measured that rescoring recovers enough recall. Do not reach for it as a default: on mid-sized collections, scalar quantization plus more RAM is usually the better engineering answer. ## Binary quantization `BinaryQuantizationConfig` reduces each component to a single bit, roughly 32x compression. Distance computation becomes bitwise work, which is dramatically faster than float arithmetic — this is the mode people choose for latency, not only for memory. The catch is that it only works when the embedding space tolerates it. High-dimensional embeddings (roughly 1024 dimensions and up) from models whose components are well-centred retain enough signal in their sign pattern; low-dimensional embeddings do not, and recall collapses. Binary quantization is also effectively unusable without oversampling and rescoring: you retrieve a wide candidate set with cheap bit distances, then re-rank with the original vectors. Validate it, always, on your own embeddings before committing. "Works great for 1536-dimensional embeddings" is a statement about particular models, not a law. ## always_ram and the storage picture Each config carries `always_ram`. Left false, the quantized vectors may be memory-mapped like everything else; set true, they are kept resident. The canonical high-value configuration is `VectorParams(..., on_disk=True)` for the originals plus quantization with `always_ram=True`: traversal touches only the small in-memory copy, and disk is read only during rescoring of the final candidates. Inverting that — originals in RAM, quantized on disk — gets you the accuracy loss without the memory saving. ## Choosing Start from the memory budget. Compute raw size as points x dimensions x 4 bytes and compare it to the RAM you are willing to buy. If raw fits with headroom, quantization is optional and scalar is a cheap latency win. If you are 3-5x over, scalar with originals on disk usually closes the gap. If you are an order of magnitude over, choose between product and binary by dimensionality and latency needs — and in every case measure recall against exact ground truth before and after, because the whole point is to know exactly how much accuracy you traded away.