Qdrant Vector Database: Payload Filtering, Quantization, Hybrid Queries, and Production Setup

Qdrant is an open-source vector database and similarity search engine written in Rust. It stores points (vectors with an ID and a JSON payload) in collections, and supports fast filtered search, quantization, sparse and dense vectors for hybrid search, and horizontal scaling. It is a popular choice for self-hosted RAG and semantic search where data must stay in your own infrastructure.

Core concepts

• Collection: a named set of points with defined vector size and distance metric (cosine, dot, Euclidean, or Manhattan).
• Point: an ID, one or more named vectors, and a payload of JSON metadata.
• Payload index: an index on a payload field that makes filtering on it fast. Create one for every field you filter on frequently, such as tenant ID or permissions.
• Snapshots for backups and migrating collections.

Python example

Install the client with pip install qdrant-client.

from qdrant_client import QdrantClient, models

client = QdrantClient(url="http://localhost:6333")

client.create_collection(
    collection_name="docs",
    vectors_config=models.VectorParams(size=768, distance=models.Distance.COSINE),
)
client.create_payload_index("docs", field_name="tenant_id", field_schema="keyword")

client.upsert(
    collection_name="docs",
    points=[models.PointStruct(id=1, vector=embedding, payload={"tenant_id": "acme", "title": "Refunds"})],
)

hits = client.query_points(
    collection_name="docs",
    query=query_embedding,
    query_filter=models.Filter(
        must=[models.FieldCondition(key="tenant_id", match=models.MatchValue(value="acme"))]
    ),
    limit=5,
).points

See the Qdrant documentation for the current client API.

Quantization: cutting memory costs

Large collections of high-dimensional vectors consume a lot of RAM. Qdrant's quantization stores compressed versions of vectors for fast search:

Rescoring with the original vectors on the top candidates recovers most of the accuracy. Always measure recall on your own data.

Hybrid and multi-stage queries

Qdrant supports sparse vectors, for example from BM25-style or learned sparse models, alongside dense vectors. The Query API can prefetch candidates from several searches and fuse them, for example with reciprocal rank fusion, which enables hybrid search and re-ranking pipelines in one request. See hybrid search explained.

Deployment

• Docker for development and small single-node workloads.
• Kubernetes with the official Helm chart for distributed, replicated production clusters.
• Qdrant Cloud for a managed service, including options to run in your own cloud environment.

Secure every deployment with API keys or JWT-based access, TLS, and network restrictions.

When to choose Qdrant

• Queries are heavily filtered by tenant, permissions, or attributes.
• Data must stay in your own cloud account or on-premises.
• Memory cost matters at scale and quantization helps.
• You prefer an open-source engine with an efficient Rust core.

Compare options in our vector database comparison.

Designing collections and payloads

In Qdrant, a collection holds points, and each point has an ID, one or more vectors, and an optional payload of JSON metadata. Design payloads around the filters your application needs: tenant ID, document ID, source, document type, language, dates, and access groups are typical. Create payload indexes for fields you filter on frequently, because indexed payload fields make filtered search far faster and help Qdrant's query planner choose an efficient strategy. Keep payloads focused; store large text in your own database or object storage and keep an ID in the payload, unless you need Qdrant to return the text directly for convenience. Use stable point IDs, either integers or UUIDs derived from your document and chunk identifiers, so updates and deletions are straightforward.

Named vectors and multiple representations

Qdrant supports multiple named vectors per point, which lets you store different representations of the same item together. For example, a product could have a text embedding of its description, an image embedding of its photo, and a sparse vector for keyword matching. Queries can target a specific named vector or combine several. Named vectors are also useful during embedding model migrations: you can add a vector from the new model alongside the old one, evaluate both, and switch queries over when ready, without maintaining two separate collections.

How filtering works in Qdrant

Many vector databases struggle when filters exclude most of the collection, because the approximate index may not find enough matching neighbors. Qdrant integrates payload filtering with its HNSW index and uses payload indexes and cardinality estimates to decide how to search, which keeps filtered queries accurate and fast even when only a small fraction of points match. Filters support exact matches, ranges, geographic conditions, nested fields, full-text matching on indexed text fields, and boolean combinations with must, should, and must not clauses. For multi-tenant applications, Qdrant's documentation recommends storing a tenant field in the payload with an index configured for tenant workloads, rather than creating thousands of separate collections.

Choosing a quantization strategy

Qdrant offers scalar, product, and binary quantization to reduce memory use. Scalar quantization converts 32-bit floats to 8-bit integers, cutting vector memory to roughly a quarter with a small effect on accuracy, and is a sensible default for many workloads. Product quantization compresses further by encoding groups of dimensions, trading more accuracy for greater savings. Binary quantization represents each dimension with a single bit, giving very large memory savings and fast search, and works best with high-dimensional embeddings from models that tolerate it well. A common pattern is to search the quantized vectors, then rescore the top candidates using the original vectors stored on disk, recovering most of the lost accuracy. Measure recall on your evaluation set for each option before choosing.

Storage, memory, and performance tuning

Qdrant can keep vectors and the HNSW graph in memory for the lowest latency, or store them on disk with memory mapping to reduce RAM usage for large collections. Payloads can also be stored on disk. HNSW parameters such as the number of links per node and the size of the candidate list during index building affect accuracy, memory, and indexing speed, while the search-time parameter controls the trade-off between latency and recall for each query. Start with defaults, measure, and adjust only when you have evidence that a change improves results for your workload.

Clustering, replication, and backups

In distributed mode, Qdrant splits collections into shards across nodes and can replicate each shard for high availability. Choose a replication factor of at least two for production, so the loss of one node does not cause downtime or data loss, and plan shard counts with future growth in mind. Use snapshots to back up collections or the whole cluster to object storage, and test restoring them regularly. Qdrant Cloud manages clustering, upgrades, and backups for you, while self-hosting on Kubernetes, often with the official Helm chart, gives full control.

Security configuration

Out of the box, a self-hosted Qdrant instance may accept connections without authentication, so secure it before exposing it to any network. Enable API key authentication, and use read-only keys for services that only query. Enable TLS for traffic between clients and the server and between cluster nodes. Restrict network access with firewalls or private networking so only your application servers can reach the database. Qdrant also supports JWT-based access control that can limit tokens to specific collections and operations, which is useful for multi-service architectures. Store keys in a secrets manager, rotate them, and enforce tenant and permission filters in your application based on the authenticated user.

Example: a recommendation feature with Qdrant

An online learning platform wants to recommend courses similar to those a learner has viewed. It stores each course in Qdrant with a text embedding of its title, description, and syllabus, and payload fields for language, level, price, category, and availability. When a learner finishes a course, the application queries for the nearest neighbors of that course, filtered to the learner's language, available courses, and levels they have not completed, and excludes courses they already own. Qdrant's recommendation API also lets the team supply several positive examples, such as recently viewed courses, and negative examples, such as courses the learner dismissed. Scalar quantization keeps memory usage low as the catalogue grows. Click-through on recommendations is tracked and used to tune the strategy over time.

Common Qdrant mistakes

• Running without authentication or TLS on a reachable network.
• Filtering on payload fields that have no payload index.
• Creating one collection per tenant for thousands of tenants instead of using a tenant payload field.
• Choosing aggressive quantization without measuring recall.
• Running a single node with no replication for production traffic.
• Never testing snapshot restores.

Monitoring Qdrant

Qdrant exposes metrics in a Prometheus-compatible format and provides telemetry and health endpoints. Track query latency percentiles, request rates, error rates, memory and disk usage, collection sizes, indexing status, and replication health. Alert on rising latency, memory pressure, failed requests, and nodes leaving the cluster. Watch for collections whose optimization or indexing is lagging after large imports, which can temporarily slow queries. Combine database metrics with application-level metrics such as retrieval recall on your evaluation set and user feedback, so you can tell whether a change in answer quality comes from the database, the embeddings, or the content.

When Qdrant is a strong fit

Qdrant is a strong choice when filtered search performance matters, for example multi-tenant SaaS, permission-aware enterprise search, or e-commerce with many attributes; when memory efficiency is important at scale, thanks to its quantization options; when you need the flexibility to self-host for data residency or cost reasons, or to use a managed cloud; and when you want features such as named vectors, sparse vectors for hybrid search, and recommendation queries in one system. For very small collections that sit alongside relational data, pgvector may be simpler; for a fully serverless managed experience, Pinecone is an alternative; and for built-in BM25 hybrid search with a schema model, Weaviate is worth comparing.

Summary

Qdrant combines fast, accurate filtered vector search with efficient memory use and flexible deployment. Design payloads and indexes around your filters, choose quantization based on measured recall, run replicated clusters with tested snapshots, secure every deployment with authentication and TLS, and monitor both database health and retrieval quality. For comparisons and next steps, see our vector database comparison, our hybrid search guide, and our vector database development guide.

Getting started checklist

1. Choose Qdrant Cloud or self-hosting based on your operations capacity, data residency, and cost requirements.
2. Create a collection with the vector size and distance metric that match your embedding model, and record the model version.
3. Design payload fields around your filters, and create payload indexes for the ones you query often, including a tenant field for multi-tenant data.
4. Use deterministic point IDs and batch upserts in your ingestion pipeline, with deletions synchronized from source systems.
5. Build an evaluation set of real queries and measure recall before tuning HNSW parameters or quantization.
6. Enable API keys, TLS, and network restrictions before any production traffic reaches the database.
7. Configure replication, snapshots, monitoring, and alerting, and rehearse a restore.

Following these steps in order gives you a secure, measurable, and scalable Qdrant deployment from the start, and makes later tuning far easier because every change can be checked against the same baseline.

Revisit the configuration as your data and traffic grow. Quantization, shard counts, and replication that suit a few million points may need adjusting at hundreds of millions, and measuring against your evaluation set keeps those decisions grounded in evidence.

Measure first, tune second, and scale with confidence.

Qdrant integration with Vertex Cyber Tech

We deploy and integrate Qdrant for production RAG and search in clients' own clouds. See our vector database capabilities and RAG implementation guide, or book a consultation.

Sources and further reading

• Qdrant documentation
• Qdrant: Quantization
• Qdrant on GitHub