What is Qdrant, and how does it work as a vector database?

In this article

1. Before you start
2. Why interviewers ask this
3. Qdrant from first principles
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This page is one step of the vector database and embeddings learning path, and it builds on the transformer architecture that produces many embeddings.

Why interviewers ask this

Retrieval is the first stage of most systems that answer questions over private documents, so a design round on one often asks you to pick and justify a vector store. Qdrant is one such store, and the question tests whether you understand what a vector database does beyond "it stores embeddings".

A weak answer lists features. A strong answer explains the data model, says why the search is approximate, shows how a metadata filter changes the plan, and states the memory cost of the vectors. A Staff-level answer adds hybrid search, reranking and compression, each with its trade-off. Questions of this kind are reported by candidates in design rounds at AI-focused companies; no public source ties them to one named company.

Qdrant from first principles

Point

A point is the unit of storage in a Qdrant collection: an id, one or more vectors, and an optional payload of metadata fields. A search returns points, ranked by how close their vectors are to the query vector under the collection's distance metric.

Payload index

A payload index is a structure built on one metadata field of a collection, such as a category or a date, that lets the database apply a filter on that field quickly while it searches vectors, instead of checking every point's metadata.

In plain words

Picture a huge warehouse. Every box has a position on a map and a label with facts such as "category: shoes". Finding the boxes nearest a spot is quick if the warehouse keeps a guide to its neighborhoods. Qdrant keeps that guide for the vectors. The analogy breaks in one place. The map has hundreds of dimensions, so "nearest" cannot be read off by eye. A printed guide is also exact, while Qdrant's guide is a shortcut that can skip a box that is truly close.

In one precise sentence, Qdrant stores points in named collections and builds an approximate nearest-neighbor index over their vectors. A query can then combine that index with filters, sparse vectors and reranking.

Step 1: A collection holds points, and the distance metric defines nearest

A collection is a named set of points whose vectors all have the same size. When you create one you choose that size and a distance metric, such as cosine, dot product or Euclidean distance. A point you insert carries an id, the vector from your embedding model, and a payload such as {"topic": "retrieval"}.

Input: your vectors and metadata. Output: a stored, searchable set. The metric must match how the embedding model was trained: with vectors scaled to length one, cosine and dot product rank results the same way. A collection can also hold several named vectors per point, for example one from a text model and one from an image model. You now know what is stored; the next step is how it is searched quickly.

Step 2: An HNSW index finds near neighbors without scanning every point

Exact search compares the query with every vector, which is too slow for millions of points. An HNSW index, short for Hierarchical Navigable Small World index, is a layered graph in which each vector links to nearby vectors; a search enters at a sparse top layer and walks greedily downward toward the query (Malkov and Yashunin, 2016). It visits a small fraction of the points, so it is fast, and it is approximate: it can miss a true neighbor.

Qdrant's indexing documentation (read 2026-10-26) shows the two build settings. m is the number of edges per node, default 16: a larger value gives a more accurate search and needs more space. ef_construct is the size of the candidate list used while building, default 100: a larger value gives a better graph and a slower build. At query time a search-side setting also sets how many candidates the search keeps, trading speed for recall. Input: a query vector. Output: the ids and scores of the closest points found. You now know why recall below 100% is expected.

Step 3: A payload index keeps filtered search fast

A filter restricts a search to points whose payload matches a condition, such as "category equals shoes". Without help, the database has to test the condition point by point while it walks the graph, or search first and discard mismatches. A payload index on the filtered field lets the engine check the condition cheaply and plan the search around it.

Qdrant's query planner estimates how many points a filter matches. When that is below full_scan_threshold_kb, the indexing page says the planner uses full-scan search over the payload index instead of HNSW traversal. For indexed fields Qdrant also builds extra graph links so filtered traversal stays connected, which is why selective filters do not break the graph. See metadata filtering. Index the fields you filter on often; each index costs memory. Input: a query vector plus a condition. Output: only matching points, ranked by distance. The vector indexing page compares HNSW with other index types.

Step 4: Hybrid queries combine dense, sparse and reranked results

Dense vectors capture meaning, and sparse vectors capture exact words, so one query can fail where the other succeeds. A hybrid query runs both searches and merges the two ranked lists, which is the idea explained in hybrid search. In Qdrant one query_points call takes a dense prefetch and a sparse prefetch, each a sub-query with its own candidate list, and a fusion query using reciprocal rank fusion (RRF), written models.Fusion.RRF, merges them (hybrid queries documentation, read 2026-10-26). For Best Matching 25 (BM25)-style scoring, the sparse vector uses the inverse document frequency (IDF) modifier, so the server computes the IDF weights (vectors documentation, read 2026-10-26). Keyword-style search then needs no separate engine.

A second stage can then reorder a short list with a slower model, a cross-encoder reranker. Input: the question as a dense and a sparse query. Output: one merged, optionally reranked list.

1 · Collection2 · HNSW index3 · Payload index4 · Hybrid queryReplay

Step-by-step description

1. A collection holds points.
2. The graph finds near neighbors.
3. Filters stay fast.
4. Result lists are merged.

• A collection holds points, each with an id, a vector and a payload.
• An HNSW index finds near neighbors without scanning every point.
• A payload index keeps filtered search fast.
• A hybrid query merges dense and sparse results into one list.

Worked example

Memory is the cost most designs must estimate. Take 10,000,000 vectors of 768 numbers each (illustrative sizes). In float32, each number takes 4 bytes, so one vector takes 3,072 bytes and the collection takes 30.72 GB before any index overhead; stored as 8-bit integers it takes 7.68 GB, and stored as one bit per number it takes 0.96 GB.¹ That is a 4 times and a 32 times reduction, by arithmetic.¹

Text description of the diagram

• 10,000,000 vectors of 768 numbers need 30.72 GB as float32.
• The same vectors need 7.68 GB as 8-bit integers and 0.96 GB at one bit per number.

Now the merge in a hybrid query. A common method is reciprocal rank fusion (RRF): each list gives a document the score 1 divided by (k plus its rank), and the scores add. RRF comes from Cormack, Clarke and Buettcher (2009), who used k equal to 60.

With that k and illustrative rankings, dense search returns A, B, C, D and sparse search returns C, A, E, B. Document A scores 0.032522, C scores 0.032266, B scores 0.031754, E scores 0.015873 and D scores 0.015625, so the fused order is A, C, B, E, D.¹ Document C was first in only one list yet lands second, because appearing in both lists is rewarded. Qdrant's Query application programming interface (API) offers RRF and a second method, distribution-based score fusion (DBSF), over prefetch sub-queries (hybrid queries documentation, read 2026-10-26).

Text description of the diagram

• Dense search returns A, B, C, D and sparse search returns C, A, E, B.
• The fused order is A, C, B, E, D.

Trade-offs and edge cases

Quantization saves memory but can lower recall, so a common pattern is to search the compressed vectors for candidates, oversample them, and rescore the best ones with the full-precision vectors; the quantization documentation (read 2026-10-26) covers scalar and binary compression, rescoring and oversampling. Measure recall on your own queries before and after; the figures above show size only, not accuracy.

Edge cases: very selective filters are handled by the planner switching to a payload-index scan, so the hard cases are a filter on an unindexed field and a mid-selectivity filter on a graph built before the payload index existed; an embedding model change means re-embedding every point, because vectors from two models are not comparable; and a collection with several named vectors needs the right name in each query. Practice differs on whether to start with hybrid search or add it after measuring dense-only failures, and both are defensible. For design framing, see semantic similarity.

How to answer it in an interview

The spoken structure: define it, say it is approximate, name filtering and hybrid search, give the memory cost, then the reranker.

Common mistakes

• "Qdrant gives exact nearest neighbors." (wrong) The index is approximate. (right) "It returns near neighbors fast, and I measure recall against exact search."
• "Filters are free." (wrong) A filter on an unindexed field can slow search. (right) "I index the fields I filter on and test selective filters."
• "Hybrid search needs a separate keyword engine." (wrong) One query_points call can take a dense and a sparse prefetch and merge them with RRF fusion. (right) "Dense and sparse vectors live in one collection, and one hybrid query fuses them."
• "Memory is the vector count only." (wrong) Dimensions and bytes per number matter too. (right) "Vectors times dimensions times bytes per number, plus index overhead."

Follow-up questions

What is Qdrant used for?

Qdrant is used for semantic search, retrieval for question-answering systems built on retrieval-augmented generation (RAG), recommendations and similar-item lookup, wherever finding the nearest vectors under a filter is the core operation. Qdrant is open source under the Apache 2.0 licence and written in Rust (official repository, read 2026-10-26). See the vector database guide for the wider picture.

How does Qdrant hybrid search work with BM25?

BM25 is a classic keyword-scoring formula, and keyword-style matching is represented in Qdrant with sparse vectors. The dense and sparse results are fused into one list, for example by rank fusion as in the worked example. In the Query API that is one query_points call with a dense and a sparse prefetch and an RRF fusion query; the sparse side uses the IDF modifier so the server computes IDF, as in Step 4.

How does reranking work in Qdrant?

A first query returns a short candidate list, and a second stage rescores it with a more precise model, such as a cross-encoder or a multi-vector model. The documentation menu lists a reranking page and a hybrid-search-with-reranking tutorial. The bi-encoder versus cross-encoder page explains why the second stage is slower and sharper.

How do I run Qdrant with Docker and try it from Python?

The quickstart shows how to download and run a local server with docker run -p 6333:6333 -p 6334:6334 qdrant/qdrant, which serves representational state transfer (REST) on port 6333 and gRPC on port 6334 (quickstart, read 2026-10-26). The Python client, qdrant-client, connects to it, and its in-memory mode is handy for tests.

Is Qdrant search exact?

No. The HNSW index is approximate, so a query can miss a true neighbor; you tune recall against speed and memory and can compare against exact search on a sample.

How do you cut the memory a Qdrant collection needs?

Use quantization, lower the vector size with a smaller embedding model, and index only the payload fields you filter on. In the worked example, 8-bit numbers cut raw vector memory by 4 times and one bit per number by 32 times. The vector indexing page covers the index-side memory trade-offs.

Sources

1. Indexing - Qdrant documentation (HNSW and payload indexes; documentation menu) — Qdrant, 26 Oct 2026
2. Qdrant documentation — Qdrant, 26 Oct 2026
3. qdrant/qdrant: Qdrant vector search engine (official repository) — GitHub (Qdrant), 26 Oct 2026
4. Hybrid Queries - Qdrant documentation — Qdrant, 26 Oct 2026
5. Vectors (dense, sparse, IDF modifier) - Qdrant documentation — Qdrant, 26 Oct 2026
6. Quantization - Qdrant documentation — Qdrant, 26 Oct 2026
7. Quickstart - Qdrant documentation — Qdrant, 26 Oct 2026
8. Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs (arXiv 1603.09320) — arXiv (Malkov and Yashunin), 30 Mar 2016
9. Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods — ACM SIGIR 2009 (Cormack, Clarke, Buettcher), 19 Jul 2009