qdrant / qdrant
Qdrant puts payload filters next to vector search, and starts with the door open
Qdrant is a vector database written in Rust. It stores points, each a vector with a JSON payload, and searches them by similarity with rich filters on that payload, over REST or gRPC, on one node or a sharded cluster. A self-hosted instance starts without authentication, so the first hour with it should include locking it down.
WHAT TO KNOW FIRST
- A point is a vector plus a JSON payload, and filters built from must, should and must_not clauses are part of the search request.
- Self-hosted Qdrant is not secure by default: the docs say it listens on all interfaces without authentication until an API key, network binding and TLS are configured.
- Dense, sparse and multivector search, hybrid fusion, quantization and on-disk storage offer many trades between memory, speed and recall, and each needs measuring on the application's own queries.
01Points, payloads and collections
The qdrant/qdrant README describes a vector similarity search engine and vector database that stores, searches and manages points, meaning vectors with an additional payload. Points live in collections, and each collection is created with a vector size and a distance metric; the quickstart creates one with four dimensions and dot product distance. Payloads are JSON, so a point can carry a document ID, tenant, language, date or any other field the application needs at query time.
The decision that matters most is where metadata lives. Keeping filterable fields in the payload lets one request ask for the nearest vectors among only the points a user may see, or only documents from the current year. Keeping them elsewhere forces the application to over-fetch and filter afterwards, which hurts both recall and latency. Design the payload the way one would design table columns: which fields are filtered on, which are only returned, and which should not be stored at all.
02Filtering is the reason to choose it
The README says Qdrant is tailored for extended filtering support. Conditions cover keyword matching, full-text matching, numeric ranges and geo-locations, combined with must, should and must_not clauses. Payload indexes and a query planner use stored payload information to pick an execution strategy. The v1.20.0 release added per-element payload indexes for arrays of objects, a code tokenizer for full-text indexes and a substring match condition, which its notes mark as full-scan only.
Filtered vector search is where naive setups break down. A filter that matches a small fraction of points makes approximate search work harder, and a filter on an unindexed field can turn into a scan. Index the fields used in filters, test with the most and least selective filters the product allows, and record latency for each. Multitenancy, which the README lists as a feature, needs the same care: make sure no code path can run a query without its tenant filter.
03Dense, sparse, multivector and hybrid search
Qdrant supports dense vectors for semantic similarity, sparse vectors for full-text style search and multivector search for objects with several embeddings or late-interaction models such as ColBERT. Hybrid search combines several vectors in one query and merges results with fusion strategies such as Reciprocal Rank Fusion and Distribution-Based Score Fusion. Relevance tools include Maximal Marginal Relevance, a relevance feedback query, and recommendation and discovery queries driven by positive and negative examples. The v1.20.0 release added BM25 scoring on the full-text payload index.
These options make it possible to build a retrieval stage that handles exact terms as well as loose meaning, which matters for product names, error codes and other text an embedding model may blur. They also multiply what has to be evaluated. Build a labeled set of real queries with the documents that should come back, and compare dense-only, sparse-only and hybrid configurations on it before choosing. Retrieval quality is measured, not inferred from a feature list.
04Memory, quantization and disk
Vector search is memory-hungry, and Qdrant offers several ways to manage it. The README says built-in quantization can cut RAM use by up to 97 percent while letting operators tune the balance between speed and precision, and vectors can be kept on disk. Asynchronous I/O through io_uring keeps disk throughput high, including on network-attached storage, SIMD acceleration covers x86-64 and Neon CPUs, and GPU support is listed for faster indexing on NVIDIA and AMD hardware. The v1.20.0 release introduced turbo8 and turbo16 vector datatypes.
Quantization trades memory for some precision, and on-disk storage trades memory for some latency. The right mix depends on collection size, query rate and the recall the product can accept. Size a test collection close to production scale, measure recall against unquantized results and watch tail latency under concurrent load. The README lists write-ahead logging for update durability, but capacity planning still needs headroom for indexing, snapshots and growth.
05A self-hosted instance starts open
The README's quick-start command runs the container with port 6333 published and warns that this starts an insecure deployment without authentication, open to all network interfaces. The security documentation repeats it: self-hosted open-source deployments are not secure by default and not production-ready, and they may be reachable by anyone on the internet. It recommends an API key, audit logging, binding to a specific interface (127.0.0.1 for local development, a private address in production) and TLS for all traffic.
Qdrant supports three kinds of API key: an admin key with full access, a read-only key for services that only query, and granular keys scoped to read or write on individual collections. Use them that way. Give the service that answers searches a read-only or collection-scoped key, keep the admin key for ingestion and operations, and rotate keys like any other credential. The v1.20.0 release made audit log output configurable to a file, stdout or stderr, which makes it easier to send audit events to an existing log pipeline.
- Never publish port 6333 or 6334 to the internet without an API key and TLS in place.
- Bind to 127.0.0.1 on laptops and to a private interface on servers.
- Keep the admin key out of application code that only needs to search.
06Running it at scale
For larger workloads, the README lists horizontal scaling through sharding and replication, with collections that can be updated or resized without downtime. Official clients exist for Go, Rust, JavaScript and TypeScript, Python, .NET and Java, and community clients cover Kotlin and PHP. The REST API is described by an OpenAPI 3.0 specification for client generation, and a gRPC interface is offered for faster production searches. A web UI at the dashboard path helps explore collections and check health.
Distribution brings its own failure modes: replica placement, shard balance, rolling upgrades and what queries return while a node is down. Test those before relying on them. Store the embedding model version alongside each collection, because vectors from a different model are not comparable, and a model change usually means a new collection and a full reindex. Snapshots and restores belong in the runbook, together with a rehearsal of restoring one.
07Edge mode and the managed service
Qdrant Edge is a lighter variant that runs inside the application process instead of as a server. According to the README it stores and queries data locally, can synchronize with a Qdrant server and suits low-latency or offline applications; from Python or Rust, a program creates an EdgeShard to manage data, run queries and restore snapshots. Qdrant Cloud is the managed service, which the README says includes a free tier and which the security docs describe as secure by default with API key authentication enabled.
Choose among the three by who should operate the database. Edge keeps search next to the code on a device. The self-hosted server gives full control and full responsibility. The managed service moves operations to the vendor and moves the data boundary with it. A team can prototype on one and move to another, but should test client and feature differences instead of assuming identical behavior.
08License and release cadence
Qdrant is released under the Apache License 2.0. The GitHub releases API listed v1.20.0, published October 22, 2026, as the latest release when this guide was checked, and its changelog adds features across search, indexing and security. The README notes that development happens on the dev branch while master is the default branch, which matters to anyone reading the source or sending a patch.
Pin the server version and the client library version together, read the changelog before upgrading, and test the upgrade on a copy of real data, since new index parameters and datatypes can change memory use and query behavior. Keep the labeled query set from earlier and rerun it after every upgrade. A vector database that returns slightly different neighbors is a product change even when nothing reports an error.
A SENSIBLE FIRST HOUR
Start small enough to learn the repo
- Follow the local quickstart: docker pull qdrant/qdrant, then run the image with ports 6333 and 6334 published and a qdrant_storage folder mounted at /qdrant/storage so the data survives the container.
- Open the web UI at localhost:6333/dashboard, then use the Python client to create test_collection with 4-dimensional vectors and dot product distance, upsert a few points with payloads and query them.
- Repeat the query with a filter on a payload field, add a payload index for the field you filter on most, and record how results and latency change.
- Before storing real data, follow the security page: set an API key, give query-only services a read-only key, bind to a private interface and enable TLS.
SOURCE LEDGER
What this review is built on
We use the project repository and first-party documentation. Access, licenses and project direction can change, so recheck the linked source before making a production decision.