Turning on Qdrant TurboQuant is a one-line config change, and the numbers hold up. What it does to a collection is easy to miss: RAM drops, disk usage goes up, and a calibration step runs on every segment. I keep seeing vector search land in WordPress and WooCommerce projects, so this seemed worth a careful look before anyone patches a production collection.
What got me reading was a piece by Chien Vu Minh on Towards Data Science. It benchmarks the method against scalar and binary quantization on 100K OpenAI embeddings and then lists where it fails, which is the part most writeups skip. Read it here.
What TurboQuant changes under the hood
Most quantizers compress the vector as it lies. Scalar quantization stretches one 255-bin grid over every dimension, whether that dimension carries signal or mostly noise, and stores a byte per value for about 4x compression. Binary quantization keeps only the sign bit and gets about 32x, with recall that gets shaky as the corpus grows. TurboQuant, which builds on a Google Research algorithm, rotates the vector through a random orthogonal matrix before compressing. Distances survive the rotation, but the energy gets spread across dimensions, so one precomputed codebook serves everything. There is no per-dimension tuning and no training on your data.
There is a second, smaller trick called length renormalization. Quantized vectors tend to point the right way but come out shorter than the original, which drags every similarity score down. Qdrant stores a per-vector scaling factor and multiplies it back in at query time. It is a cheap correction, and it shows up in the recall numbers.
Turning it on without recreating vectors
You do not rebuild anything. The patch runs against the live collection and Qdrant re-encodes vectors in the background. The originals stay untouched. The whole change from the source article:
from qdrant_client import QdrantClient, models
client = QdrantClient("localhost", port=6333)
client.update_collection(
collection_name="products",
quantization_config=models.TurboQuantization(
turbo=models.TurboQuantQuantizationConfig(
bits=models.TurboQuantBitSize.BITS4,
always_ram=True,
)
),
)Three things to decide before you run it:
- The server version. The quantizer shipped in Qdrant 1.18, released in May 2026. Older servers do not have it.
- The bit depth. Start at bits4, which compresses about 8x against scalar’s 4x. In the benchmark it reached 0.965 recall at 100K vectors against scalar’s 0.980, and rescoring closed the gap to 0.996 vs 0.993. The source found 1.5-bit with rescoring to be the practical floor, and 1-bit too risky at scale.
- Rescoring. Leave it on. It scores candidates against the original vectors, and TQ 4-bit plus rescoring still ran a 6.4 ms median in the benchmark, faster than the 7.6 ms float32 baseline. It also needs those originals on disk, which is where the costs below come from.
The costs the benchmarks do not headline
The quantizer is a second layer on top of the original vectors. Qdrant keeps the compressed codes in RAM for graph traversal and holds the original float32 vectors on disk for rescoring. Enable it and memory drops while total disk usage goes up, because the collection now carries both copies. The Qdrant 1.19 release notes put that at 36 bits per coordinate for both copies, and shipped a TurboQuant storage datatype that drops the original and cuts storage up to nine times. If disk is your constraint, the storage datatype matters more than the quantization layer.
A few smaller costs. Calibration runs once per segment and takes seconds, but a store that syncs products all day creates and merges segments constantly, so the cost repeats. Rotation preserves L2, dot product and cosine well; Manhattan needs full vector reconstruction per comparison, so scalar quantization is the safer pick there. And binary quantization is still faster at equal storage, which matters when throughput beats recall.
Whether a WordPress build needs this at all
The source’s arithmetic: a 1536-dimension float32 embedding is 6KB, so a million vectors is about 6GB. Run it the other way. A store with 50K products embeds to roughly 300MB, which fits in RAM on an ordinary VPS. Add product pages, documentation and support tickets, and you might reach a few hundred thousand vectors, still in the low gigabytes. Quantization starts paying when you are into millions of vectors, when the host bills for RAM, or when the vector container shares a small box with the database and PHP.
There is also a question of benchmark selection. The dataset was DBpedia, picked partly because its variance across dimensions is 233x, the sort of skew that rotation fixes. Product embeddings from one model over one catalog can be flatter, and on flatter data the gap between the two methods shrinks. The Qdrant quantization docs say results vary by dataset and model, sometimes ahead of scalar, sometimes behind. Measure on your own vectors before making it a default, which is where the source lands too.
If you are earlier in the build, the posts on stopping at embeddings for WooCommerce search and cutting vector costs with MRL and int8 cover the decisions that come before quantization.
If you are adding semantic search to a WooCommerce site and want a hand sizing the vector side, or running a quantization comparison before it ships, that is work I do.
For today, snapshot the collection with client.create_snapshot, restore it under a test name, patch the copy with bits4, and run a hundred real customer queries against both collections. Compare the top-10 overlap. A test on your own embeddings settles the question better than any benchmark here, including the source’s.
