Qdrant 1.20 adds turbo8 and turbo16 datatypes and per-element nested indexing

Smaller vectors built on TurboQuant

Storing vectors is the main expense in semantic search, Qdrant says: they cost disk when cold and memory when warm. The new datatypes reduce the bits stored per dimension. turbo8 uses 8 bits and turbo16 uses 16, so a collection takes a quarter (turbo8) or half (turbo16) of the space of float32. For teams running out of RAM or disk, Qdrant says this means fewer nodes, or room for more data on existing ones.

The company contrasts the approach with the existing float16 and uint8 types. Converting float32 to those formats loses precision and also information, because the compression relies on simple transformations. The new datatypes use TurboQuant, a rotation-based compression algorithm that Qdrant says works well on most datasets, helped by a couple of additions of its own. It keeps the relevant information while lowering precision.

The 4-bit turbo4 datatype from version 1.19 saves more, at 8x less storage, but gives up a few percentage points of recall on some datasets. Qdrant suggests it for cases where resource limits matter more than search quality.

To use the new types, a user picks one when creating a collection by setting datatype to turbo8 or turbo16. Regular float32 vectors can still be uploaded, and Qdrant rotates them with TurboQuant and stores them on an 8-bit or 16-bit integer grid.

Latency within 10% of float32

Quantization can raise latency, Qdrant acknowledges, but it reports that turbo8 and turbo16 stay within 10% of the server-side latency of float32 vectors. The query is not run through the full TurboQuant pipeline. It is only rotated and kept at float32 precision, an approach called asymmetric scoring, which keeps overhead minimal.

Scalar and binary quantization work differently. They keep full-precision copies alongside the shrunken vectors and can rescore top candidates against the originals to recover recall. When those originals sit on disk, each query waits on disk reads. Skipping rescoring avoids the wait but lowers recall. The TurboQuant datatypes have no rescoring step, since the compact vectors are the stored vectors and the float32 originals are discarded. According to Qdrant, recall stays close to float32.

The company says it tested every datatype on 14 embedding datasets with 512 to 3,072 dimensions, using HNSW as the index and exact search as ground truth. The published figures use three datasets with 1,536 dimensions, a limit of 100 results and 2x oversampling for scalar and binary quantization. The code is in the modern-quantization-bench repository.

Per-element indexing for nested filters

The second feature targets metadata payloads that contain arrays of objects, such as the authors of a paper. A nested filter looks for a single element that meets every condition, for example an author with the first name Ada and the last name Hopper.

Until now, Qdrant handled this in two steps. An index lookup found candidate points matching every condition, though not necessarily within the same element. Qdrant then read the payloads of those candidates, from disk or memory, to keep only points where one element satisfied all conditions. With 1.20, per-element indexing lets Qdrant skip the second step and evaluate the whole filter through index lookups alone.

On 1 million arXiv papers, Qdrant reports that the per-element index served up to four times as many queries per second as regular indexes, with the same correct results. The code is in the nested-filters-bench repository.

Qdrant also compares this with flat filters, which check each condition independently using index lookups only. They are usually the fastest, but because conditions can match different elements of an array, they return many false positives on arrays of objects. In the benchmark, a flat filter was close in speed but missed between a fifth and a third of the right papers.

How to enable the features

A per-element index is created by setting nested to the array key when creating a payload index on a field inside its elements. In Qdrant's example, the field authors[].first is indexed as a keyword with nested set to authors. The same index must be created for each field used in the filter.

Qdrant says existing nested filters get faster without any change to the search request. Both features are available in Qdrant 1.20, and the company invites feedback on its Discord.

For teams that run Qdrant, the release offers two separate levers: lower storage cost with turbo8 or turbo16, and faster nested filtering through an index change. All performance figures here come from Qdrant's own benchmarks.