Qdrant 1.20 Stores Vectors on a Quarter of the Bits, With Measured Recall

TL;DR

• Qdrant is an open-source vector database that teams run to keep embeddings next to their metadata and search them by similarity, and version 1.20 adds two storage datatypes and a faster way to filter nested metadata.
• Qdrant published the measurements on 2 November 2026: turbo8 keeps a vector on 8 bits per dimension and turbo16 on 16, so the same collection takes a quarter or half of the float32 space.
• TurboQuant rotates the vector before compression, which is why the datatypes keep information that a plain float16 or uint8 cast throws away, and why the stored vector carries enough signal to search without the original.
• The query keeps float32 precision while the stored vector stays compressed, and that asymmetric scoring holds server-side latency within 10% of a float32 collection.
• Scalar and binary quantization keep a full-precision copy and rescore candidates against it. The TurboQuant datatypes discard the originals, so a query never waits on a disk read to recover recall.
• The second feature indexes array elements one at a time, so a nested filter for one author with a given first and last name resolves through index lookups alone and reads no payloads.
• On 1 million arXiv papers, that per-element index served up to four times as many queries per second as a regular nested index with the same results. The flat filter answered quickly and missed between a fifth and a third of the right papers.
• Both features are configured per collection, and Qdrant reports their measurements in separate benchmarks: quantization across 14 embedding datasets and nested filtering over 1 million arXiv papers.
• The practical reading: storage is the recurring bill in a vector deployment, and the datatype decision plus one payload index setting is where that bill is set.

According to Qdrant's v1.20.0 release notes, Qdrant 1.20 combines TurboQuant datatypes and per-element payload indexes with BM25 scoring directly on the full-text payload index, a code tokenizer for that index, configurable audit-log output to a file, stdout or stderr, and full-scan substring filters. The 2 November write-up does something rare in vendor material: it publishes recall against latency, states the dataset count and dimensions, names the two benchmark repositories, and states where the compression stops paying.

Vector storage is the line item quantization attacks

A vector collection costs disk while it is cold and memory while it is warm, and the write-up says so directly. Each dimension of a float32 embedding uses 32 bits. Quantization reduces the bits per dimension, which reduces the node count a team needs or the amount of data that fits on the nodes it already runs.

The interesting part is the choice of algorithm. Casting float32 into float16 or uint8 loses precision and loses information, and the post is blunt that the compression there relies on simple transformations. TurboQuant rotates the vector first and stores the result on an 8-bit or 16-bit integer grid, so the compressed representation retains the structure that similarity search needs. The older turbo4 datatype from version 1.19 saves even more, at eight times less storage, and gives up a few percentage points of recall on some datasets.

turbo8 and turbo16 keep the query in float32

The obvious objection to a compressed vector is latency: the engine has to unpack it before it can compare. Qdrant avoids most of that cost by leaving the incoming query alone. The stored vectors are quantized, the query is rotated and kept in float32, and the comparison runs between a compressed stored vector and a full-precision query. The post calls it asymmetric scoring, and the measured outcome is a datatype that stays within 10% of the server-side latency of float32 vectors.

That number deserves the adjective narrower than it usually gets. It is server-side latency on three datasets of the same dimension, which is a real measurement and a limited one. Teams running 768-dimension embeddings from a different model family should read the direction of the result, then measure their own recall at their own candidate limit, because the recall curve depends on the data.

Rescoring disappears when the stored vector is the vector

Scalar and binary quantization also reduce vector storage. They shrink the vectors that Qdrant searches, keep the full-precision copies as well, and rescore the best candidates against those originals to recover recall. When the originals sit on disk, which is the normal case when memory is the constraint, every query waits for disk reads. A team can skip the rescoring step and lose recall, and the post names that trade honestly.

The TurboQuant datatypes remove the step altogether. The compact vector is the vector, the float32 originals are discarded, and nothing waits on the disk. For an operator, that changes the capacity model: memory holds the searchable representation and there is no second copy to size for. It also changes the recovery model, since there is no original to fall back to if a rebuild goes wrong, and a collection becomes a thing you re-embed from the source documents, because its own storage holds no pristine copy any more.

Filtering nested metadata costs a payload read per candidate

The second feature addresses nested metadata filtering, and it may matter more in daily use. Payloads in a vector database are often arrays of objects: the authors of a paper, the tags on a product, the line items of an invoice. A nested filter asks for one element that meets every condition, such as an author whose first name is Ada and whose last name is Hopper.

Before this release Qdrant answered that in two steps. An index lookup found the points that matched each condition, which allowed the first name to match one author and the last name to match another, and then the engine read the payloads of those candidates to keep only the points where a single element satisfied both. The new per-element index gives every array element its own index entry, so the second step disappears and the filter resolves through index lookups.

The configuration is one parameter on an existing payload index, and it belongs to the index, so the queries running against that field keep their shape. That is the part worth internalising for anyone who owns the schema. Creating the index with nested set to the array key speeds up the nested filters already running against that field, and no search request changes. The benchmark that supports it uses 1 million arXiv papers, and its comparison of a flat filter is the honest part of the write-up: flat filters are usually the fastest mode, and on arrays of objects they return many false positives, missing between a fifth and a third of the right papers.

What the benchmark proves about a collection larger than memory

The benchmark setup is specified well enough to be reproducible, which is the standard that separates a measurement from a marketing claim. HNSW is the index, exact search supplies the ground truth, the run covers 14 embedding datasets between 512 and 3,072 dimensions, the figures shown use the three datasets at 1,536 dimensions, the result limit is 100, and scalar and binary quantization run with 2x oversampling. Both benchmark repositories are named in the post.

That setup answers a specific question: how much recall a datatype loses at a fixed search configuration. A platform team must next measure how the choice behaves against its own embeddings and filter mix. The useful move is to take the datatype as a parameter of the collection design and run the team's own evaluation set through it, because the recall gap between float32 and an 8-bit grid is a property of the data as much as of the codec.

Choosing a datatype per collection

Qdrant sets the datatype when a collection is created, through the vectors configuration, and a team uploading ordinary float32 vectors afterwards gets them rotated and stored on the integer grid. Changing the choice on an existing collection means building a collection with the new setting and moving the data into it, so the decision is a migration, and a migration means re-embedding or re-uploading a corpus whose size is the reason the team is reading the post.

A workable rule for a first pass: start at turbo16 for a corpus that must hold recall, drop to turbo8 when memory is the binding constraint, and treat turbo4 as the option for archives where a few points of recall are an acceptable price. Then measure. The post's own figures put turbo8 and turbo16 at recall comparable to float32 on the datasets it used, and a 10% latency band that is small enough to disappear inside the rest of a request's budget.

For teams building a retrieval layer into a product, the deeper signal is that this class of release is about the cost floor. Chunking strategy, embedding model and index parameters decide the monthly bill long before the application code does, and the same choices show up in the retrieval layer behind a private AI assistant for your documents, where a corpus of scanned contracts or support tickets has to stay searchable on hardware the team controls.

Sources

• Faster and Cheaper Search With Qdrant 1.20, Qdrant blog, 2 November 2026
• Qdrant v1.20.0 release notes, github.com/qdrant/qdrant
• Indexing, Qdrant documentation, payload indexes and nested fields

Source: the Qdrant 1.20 performance post, the v1.20.0 release notes and the indexing documentation, all fetched on 10 November 2026. Those pages provide the cited bit widths, storage ratio, latency band, 14-dataset benchmark and filter benchmark over 1 million papers.