Qdrant

Filtering that happens during the search

Qdrant's distinguishing property is where the filter runs. Conditions are applied during the search rather than after retrieval.

That sounds like an implementation detail and it is a correctness feature. The common alternative, retrieving the nearest neighbours and then discarding the ones that fail your filter, has two failure modes. You get fewer results than you asked for, silently, because some of the top-k were filtered out. And in a multi-tenant system it is the shape context security describes as the leak nobody tests: post-filtering looks correct right up to the query whose true nearest neighbour belongs to someone else.

Filtering inside the search removes both. You get k results that satisfy the condition, and the vectors you were not allowed to see were never candidates.

Payloads and the filter clauses

A payload is arbitrary JSON attached to a point. Stock availability, location, price, tenant, whatever your business logic filters on.

Filters compose from three clauses, and the names are the semantics:

Nesting them covers most of what a SQL WHERE would express, which is more than the flat key-value matching several stores offer.

Payload indexes are not optional in practice

The documentation is direct: create payload indexes for the fields you plan to filter on, and "for best results, create payload indexes before ingesting data."

Both halves matter. Without an index, filtering still works and gets slow, which presents as the database being slow rather than as a missing index. And creating the index first avoids reindexing a corpus you have already loaded.

So the design step is listing your filterable fields before your first write. That list is usually short and stable: tenant, document type, date, status.

Index types are typed rather than generic: keyword, integer, bool, float, datetime, geo, full-text and uuid, each supporting different conditions such as match, range, geo operations and text search. Choosing the right type is what makes a range query or a geo query work at all, so the field's type is a real decision rather than a formality.

Where it sits among the alternatives

Against the neighbours in this section:

Supabase Vector gives you filtering through an ordinary SQL WHERE, which is the most familiar option if your data is already relational. Weaviate leads on hybrid search. Pinecone leads on not operating anything, and uses namespaces for isolation. Chroma is the easiest start.

Qdrant's case is a rich filter language applied correctly during search, with the option to run it yourself. Reach for it when your queries are "nearest neighbours, among these" rather than "nearest neighbours", and when getting that second clause right matters.

What you still own

Running it yourself means the usual list: deployment, backups, upgrades, and capacity. A managed option exists, and the choice between them is the same own-it-or-rent-it question closed vs open source models raises one layer up, with the same answer shape: data residency and control on one side, not operating a system on the other.

And the index parameters underneath are the ones indexing embeddings describes. A filtered search changes the recall picture, because restricting candidates interacts with how an approximate index traverses them. Measure recall with your filters applied, not on unfiltered queries, or the number you trust is for a query you never run.

Further reading

• Qdrant, Filtering: the clauses, payload indexes, and filtering during search.
• Context security: why post-filtering is a tenant-leak shape.
• Supabase Vector and Weaviate: the other filtering answers.
• Indexing embeddings: measuring recall, with filters applied.