# Qdrant

Qdrant is an open-source vector search engine written in Rust, known for payload filtering, quantization and hybrid dense-sparse search. Learn how it works.

## Overview

Qdrant is an open-source vector search engine and database. It stores points, each made of one or more vectors plus a JSON payload of extra data, and finds the points closest to a query vector. It is written in Rust, released under the Apache 2.0 licence, and developed by Qdrant Solutions GmbH, a company founded in Berlin in 2021. You can run it from a single Docker container, on [Kubernetes](/tools/kubernetes), or as the managed Qdrant Cloud service.

Qdrant is best known for filtering. Many real searches are not "find anything similar" but "find similar items that are in stock, in this price range, in this user's language". Qdrant builds filtering into the search itself, so it can apply strict conditions without losing speed or accuracy. It also offers several forms of vector compression, sparse vectors for keyword-style matching, multi-vector support and a query API that combines dense and sparse results for [hybrid search](/tools/hybrid-search).

Picture a large clothes shop with a skilled assistant. You show a photo of a jacket and say "something like this, in medium, under 100, in a dark colour". A poor assistant brings ten similar jackets and then discards the ones that fail your conditions, leaving you with two. A good one keeps your conditions in mind while searching and comes back with ten that fit. Qdrant tries to be the good assistant.

## What it is

| Part | Role |
|---|---|
| Collection | A named set of points sharing vector configuration |
| Point | An ID, one or more vectors and a payload |
| Payload | JSON data attached to a point, used for filtering and returned with results |
| Named vectors | Several vectors per point, such as text and image, each with its own settings |
| Sparse vectors | Vectors with mostly zero values, used for keyword-like matching such as [BM25](/tools/bm25) or SPLADE |
| Multivectors | Several vectors per field for late-interaction models such as [ColBERT](/tools/colbert) |
| HNSW index | Graph index for fast approximate search, aware of payload filters |
| Payload index | Index on payload fields for fast filtering |
| Quantisation | Scalar, binary and product compression of vectors |
| APIs | REST and gRPC, with clients for Python, TypeScript, Rust, Go, Java and others |

## Where it came from

Qdrant was created by Andrey Vasnetsov, who serves as chief technology officer, and the company was founded in 2021 in Berlin with Andre Zayarni as chief executive. The choice of Rust aimed at predictable performance and memory safety. From the start the project focused on combining vector similarity with structured filtering, which many early vector libraries handled poorly.

Over its releases Qdrant added the features that modern retrieval systems need. These include named vectors, scalar, binary and product quantisation, sparse vectors, multivector fields for late-interaction models, a universal query API with prefetch stages and result fusion, distributed deployment with sharding and replication, and tooling for multi-tenancy. On the commercial side it offers Qdrant Cloud on major cloud providers and a hybrid cloud option that runs the data plane in a customer's own Kubernetes clusters. Release notes on the official site give the exact version history.

## How it works

### Step 1: Create a collection

You define the vector size and distance measure, such as cosine, dot product, Euclidean or Manhattan. You can define several named vectors and sparse vectors in one collection.

### Step 2: Upsert points

Each point has an ID, vectors and a payload, for example `{"category": "shoes", "price": 79, "in_stock": true}`. Writes go to a write-ahead log first, then into segments.

### Step 3: Index payload fields

You create payload indexes on fields you will filter by, such as keyword, integer, float, geo, datetime or full-text. This lets Qdrant estimate how selective a filter is and plan the search.

### Step 4: Build the HNSW graph

Vectors are indexed with [HNSW](/tools/hnsw). Qdrant adds extra links in the graph for indexed payload values, so a filtered search can still navigate the graph instead of falling apart when many points are excluded. When a filter is very selective, the planner may instead use the payload index and check vectors directly.

### Step 5: Compress vectors

Quantisation stores a compact copy of each vector in memory, with the originals on disk:

- Scalar quantisation: about 4 times smaller, using 8-bit values.
- Binary quantisation: up to 32 times smaller, using one bit per dimension; works best with some high-dimensional embeddings.
- Product quantisation: very high compression with more accuracy loss.

Searches use the compressed vectors first, then rescore the best candidates with the originals to recover accuracy.

### Step 6: Query

The query API can search dense, sparse or multivector fields, apply filters, and combine several sub-queries. A common hybrid pattern prefetches candidates from a dense vector and a sparse vector and fuses them with reciprocal rank fusion.

```python
from qdrant_client import QdrantClient, models

client = QdrantClient(url="http://localhost:6333")
hits = client.query_points(
    collection_name="products",
    query=query_vector,
    query_filter=models.Filter(must=[
        models.FieldCondition(key="in_stock", match=models.MatchValue(value=True)),
    ]),
    limit=10,
)
```

### Step 7: Distribute

In a cluster, collections are split into shards spread across nodes, with replicas for availability. Tenants can be separated by payload-based partitioning within one collection or by custom shard keys.

## Key concepts and terms

| Term | Meaning |
|---|---|
| Point | The basic record: ID, vectors and payload |
| Payload | Structured JSON data attached to a point |
| Filterable HNSW | An HNSW graph extended so filtered searches stay accurate |
| Payload index | An index on a payload field for fast conditions |
| Query planner | Logic that chooses the search strategy for a filter |
| Scalar quantisation | Compressing each value to 8 bits |
| Binary quantisation | Compressing each value to 1 bit |
| Rescoring | Re-ranking top candidates with original vectors |
| Prefetch | Gathering candidates from sub-queries before final ranking |
| Reciprocal rank fusion | Merging ranked lists by summing inverse ranks |

## A worked example

An illustrative online furniture store has 2 million products and wants "shop the look" search from photos and text, with strict filters.

1. Each product gets a 768-dimensional image vector and a 768-dimensional text vector as named vectors, plus a sparse vector for keyword matching on names and codes.
2. Payload holds category, price, colour, stock status and delivery region. The team creates payload indexes on all of them.
3. Raw dense vectors take 2 million × 2 × 768 × 4 bytes, about 12.3 GB. With scalar quantisation in memory and originals on disk, RAM use for vectors drops to about 3.1 GB.
4. A typical query is a photo of a sofa with filters: category sofa, price under 900, in stock, deliverable to the user's region. Only about 3 per cent of products pass these filters.
5. Because filtering happens inside the graph search, the query still returns 20 good matches in tens of milliseconds, instead of returning a handful after post-filtering.
6. For text queries, the system prefetches from the text vector and the sparse vector and fuses them, so "oak TV unit 160cm" matches both meaning and exact terms.
7. On a labelled test set of 500 queries, hybrid search with filters gives clearly better top-10 results than dense search alone in this example.

The numbers are illustrative. The pattern, named vectors, indexed payloads, quantisation and fused queries, is typical of Qdrant deployments.

## Strengths and limitations

**Strengths:**

- Filtering is integrated into the search, staying accurate even with strict conditions.
- Several quantisation options with rescoring to save memory.
- Dense, sparse and multivector search in one engine.
- Flexible query API for hybrid and multi-stage retrieval.
- Written in Rust, with efficient resource use.
- Open source under Apache 2.0, with managed and hybrid cloud options.

**Limitations:**

- Not a general-purpose database for joins and transactions.
- Payload indexes must be planned; filtering on unindexed fields is slower.
- Heavy compression, especially binary, can hurt recall on some models.
- Distributed clusters still need capacity planning and monitoring.
- Embeddings must be produced outside Qdrant, or through its separate inference options, rather than by built-in modules for every provider.

## How it compares with alternatives

| System | Language and licence | Notable strengths | Consider when |
|---|---|---|---|
| Qdrant | Rust, Apache 2.0 | Filterable HNSW, quantisation, hybrid query API | Search with many structured conditions |
| [Weaviate](/tools/weaviate) | Go, BSD-3 | Vectoriser modules, built-in hybrid, multi-tenancy | You want model integrations inside the database |
| [Milvus](/tools/milvus) | Go and C++, Apache 2.0 | Many index types, GPU, billion scale | Very large datasets |
| [pgvector](/tools/pgvector) | C, PostgreSQL licence | Vectors next to relational data | Moderate scale on existing Postgres |
| [Elasticsearch](/tools/elasticsearch) | Java | Mature full-text search plus vectors | Text search is the main workload |

## Practical guidance and best practices

1. Create payload indexes for every field you filter on before loading large volumes.
2. Choose the distance measure the embedding model was trained for.
3. Use named vectors when a point has several kinds of content.
4. Start with scalar quantisation and rescoring; test binary quantisation on your own model first.
5. Combine dense and sparse vectors for queries with names, codes or rare words.
6. Measure recall and latency with your real filters, since filters change performance.
7. Plan sharding and replication for production; use payload-based partitioning for many small tenants.
8. Take regular snapshots and test restores.

## Common mistakes

- Filtering on fields without payload indexes and then seeing slow queries.
- Creating one collection per user when payload-based multi-tenancy would be simpler.
- Applying binary quantisation to a model it does not suit and losing recall.
- Using only dense vectors for queries that depend on exact product codes.
- Ignoring rescoring settings and accepting compressed-only accuracy.
- Exposing the API publicly without an API key or network controls.

## Frequently asked questions

### Is Qdrant free?

Yes, the engine is open source under Apache 2.0 and free to self-host. Qdrant Cloud is a paid managed service, with a small free tier described on the company's site.

### Why is Rust important here?

Rust gives low-level control over memory and performance without a garbage collector, while preventing many memory-safety bugs. For a search engine this helps keep latency predictable.

### How does Qdrant handle filters differently?

It extends the HNSW graph with links based on indexed payload values and uses a planner to pick a strategy. This keeps filtered searches accurate and fast, rather than searching first and filtering afterwards.

### Can Qdrant do keyword search?

It supports sparse vectors, which can represent BM25-style or learned sparse scores, and full-text payload indexes for filtering. Combined with dense vectors, this gives hybrid search.

### Does Qdrant create embeddings for me?

Usually you create embeddings in your application, for example with the companion FastEmbed library or any model provider, and send vectors to Qdrant. Check the documentation for current built-in inference options.

### Which ports does it use?

By default the REST API listens on port 6333 and gRPC on port 6334.

## Glossary

- Vector search engine: software that finds nearest vectors to a query.
- Payload: extra structured data stored with each vector.
- Sparse vector: a vector with few non-zero values, like weighted keywords.
- Dense vector: a vector with mostly non-zero values from an embedding model.
- Quantisation: storing vectors with fewer bits.
- Shard: a partition of a collection on one node.
- Replica: a copy of a shard for availability.
- Snapshot: a saved copy of a collection for backup.

## Summary

Qdrant is an open-source vector search engine written in Rust and developed by Berlin-based Qdrant Solutions, founded in 2021. It stores points with vectors and JSON payloads, and its filter-aware HNSW index keeps searches accurate under strict conditions. Scalar, binary and product quantisation with rescoring save memory, while sparse vectors, multivectors and a flexible query API support hybrid and multi-stage retrieval. It suits production search and RAG systems where structured filters matter, as long as payload indexes, compression and cluster settings are planned and measured.