A general search engine with vectors, or a dedicated vector database? A factual comparison of retrieval features, licensing and deployment, and when each one fits your AI search, RAG and agent workloads.
| Feature | Elasticsearch | Qdrant |
|---|---|---|
| What it is | Search and analytics engine with lexical, vector and aggregation features | Vector database and vector search engine |
| License | Source available under Elastic License 2.0, SSPL 1.0 or AGPLv3 (your choice) | Apache 2.0 |
| Deployment | Elastic Cloud Hosted, Elastic Cloud Serverless, self-managed, ECE, ECK | Self-hosted, Qdrant Managed Cloud, Hybrid Cloud, Private Cloud |
| Lexical search | BM25 with configurable text analysis | BM25 and text filtering |
| Dense vectors | dense_vector field, HNSW, up to 4096 dims | Dense vectors; several named vectors per point |
| Sparse vectors | sparse_vector field (e.g. ELSER) | Sparse vectors |
| Hybrid fusion | RRF retriever | RRF and DBSF in the Query API, plus multi-stage rescoring |
| Quantization | int8, int4 and BBQ; float vectors quantized by default in recent versions | Scalar, binary and product; originals kept for rescoring |
| Filtered vector search | Filters inside the kNN clause are applied during search | Payload indexes add filter-aware links to the HNSW graph |
| Scaling | Shards and replicas | Shards, custom shard keys, replication; Raft for cluster state |
| Analytics & logs | Aggregations, observability and logs | Not the focus |
Based on the official Elastic and Qdrant documentation. Features change between versions - check the docs for the release you run.
Vectors sit next to a mature lexical engine. The dense_vector field uses HNSW and, in recent versions, quantizes float vectors by default (int8, int4 or BBQ), sparse_vector holds learned sparse features such as ELSER, and the RRF retriever fuses BM25 and kNN results. Filters placed inside the kNN clause are applied during the vector search, so you still get k matches.
Each point can carry several named dense vectors, sparse vectors and multi-vectors scored with MaxSim, plus a JSON payload. The Query API prefetches from each and fuses with RRF or DBSF, then can rescore with a larger vector or a multi-vector model. Payload indexes extend the HNSW graph with extra links so filtered vector search stays accurate, and a tenant flag on a payload index optimises storage for multitenant data.
Both engines quantize vectors to cut memory. Qdrant offers scalar, binary and product quantization, keeps the original vectors alongside, and rescores top candidates with them, with oversampling to trade speed for recall. Originals can live on disk, at the cost of slower rescoring.
Both scale out with shards and replicas. Qdrant adds user-defined shard keys (for example per tenant) and uses Raft to keep cluster topology consistent; changing the shard count of an existing collection (resharding) is available in Qdrant Cloud. Elasticsearch brings a broader operational ecosystem: aggregations, observability and several managed and orchestrated deployment options.
Many teams run both: Elasticsearch for lexical search and analytics, Qdrant for vector retrieval behind RAG and agents. The right answer comes from testing each on your own queries.
Qdrant's migration tool copies vectors and metadata from Elasticsearch and OpenSearch. We handle the rest: collection and payload design, re-creating filters and ranking, and comparing retrieval quality before and after so the cutover is a measured decision.
Elasticsearch is a general search and analytics engine that added vector search to a mature lexical engine. Qdrant is built specifically for vector search: it stores dense, sparse and multi-vectors per point with filterable payloads. Elasticsearch covers more ground; Qdrant goes deeper on vector retrieval.
Choose Qdrant when vector retrieval is the main workload and you want named vectors, multi-vectors, quantization with rescoring and filter-aware vector indexing in a dedicated engine. Choose Elasticsearch when you also need lexical analyzers, aggregations or logs, or when adding vectors to an existing cluster is simpler.
Yes. Elasticsearch combines BM25 and vector results with its RRF retriever. Qdrant combines dense and sparse vectors through prefetches in its Query API, fused with RRF or DBSF, and can rescore candidates in further stages.
Yes. Qdrant is licensed under Apache 2.0. Elasticsearch source code is available under your choice of Elastic License 2.0, SSPL 1.0 or AGPLv3.
Yes. Qdrant provides a migration tool that supports Elasticsearch and OpenSearch as sources. Plan for more than a data copy: filters, ranking and lexical behaviour need to be re-created and retrieval quality compared before cutover.
Tell us about your data and queries. We will help you test both on your workload and recommend the right setup.
