# Qdrant filtered HNSW: payload indexes are part of the search plan

A metadata filter changes the search problem in Qdrant, rather than merely hiding rows after retrieval.

Author: Retrivium team
Updated: 2026-11-03
Canonical URL: https://retrivium.ai/journal/qdrant-payload-index-filtered-hnsw/
Language: en

A metadata filter changes the search problem in Qdrant, rather than merely hiding rows after retrieval. Diagnose filtered HNSW with the intended predicate and payload indexes, because an unfiltered benchmark does not describe a selective search workload.

## Separate the two index roles

Qdrant's [indexing documentation](https://qdrant.tech/documentation/manage-data/indexing/) distinguishes payload indexes from vector indexes and explains their relationship in filterable HNSW. A payload index describes values used in conditions; a vector graph organizes similarity neighborhoods. Creating one cannot be treated as creating the other. The operational question is which candidate population satisfies the requested condition and how the engine searches that population.

## Make the predicate a test artifact

Store the exact filter expression with every relevance judgment. The [filter reference](https://qdrant.tech/documentation/search/filtering/) matters especially for arrays and nested objects: two field conditions need not mean that the same object satisfies both. First validate the predicate against known records independently of similarity. A correctly ranked but unauthorized or wrongly matched point is still a failed result, even when its vector score looks convincing.

## Build a selective fixture

Consider an illustrative document collection with language and product-family fields. Prepare a query whose relevant documents lie inside one requested product family, plus similar documents outside it. Compare the filtered result with an exact reference over that same allowed population. The unfiltered nearest neighbors are not its gold answer. Preserve actual document IDs so a changed filter cannot silently redefine which results count as correct.

| Check | Question |
|---|---|
| Predicate | Are the intended records eligible? |
| Payload index | Is the queried field indexed appropriately? |
| Vector result | Are relevant eligible records recovered? |

## Inspect vector configuration separately

The [vector reference](https://qdrant.tech/documentation/manage-data/vectors/) defines the metric and representation for each vector field. Preserve those settings together with the embedding revision. A filter experiment must not also replace the distance metric or query encoder. Equal dimensions cannot prove that two vector spaces are compatible. If relevance changes after a model migration, establish representation consistency before interpreting graph-search behavior.

## Compare the actual workload distribution

Test restrictive and broad predicates, including fields with different correlations to semantic neighborhoods. Record result count, recall against the filtered reference, elapsed time and failures. Do not assume that the same optimization helps every predicate. For a small fixture, exact search is a useful correctness control; its purpose is to explain missing results rather than prescribe a universal replacement for approximate indexing.

## Distinguish fixes from accidental changes

After adding or changing an index, preserve the schema state and repeat the identical queries. Do not change candidate limits, filters and embedding files together. If the filter itself was wrong, fix the judgment population before tuning retrieval. If the predicate is correct but eligible evidence is missed, inspect the documented vector-search path. This sequence produces an explainable filtered-search result rather than a vague conclusion that the database needs more RAM.

Related reading: [Qdrant for RAG: deciding what belongs in RAM or on disk](/journal/qdrant-memory-on-disk/); [Vector-database memory: choosing RAM and storage for retrieval](/journal/vector-database-memory-hosting/).