Qdrant and Weaviate: open-source vector search with filtering and hybrid built in
Two capable open-source stores, each with a managed cloud. We help you pick the one that fits your filtering, hybrid and hosting needs, then deploy and tune it.
Qdrant and Weaviate sit between pgvector, which lives inside Postgres, and Milvus, which is built for cluster scale. Both are dedicated vector databases that one team can operate, with filtering and hybrid retrieval as first-class features rather than add-ons.
Qdrant
Written in Rust. Payload filtering is part of the search itself, quantisation options cut memory, and sparse vectors enable hybrid retrieval. REST and gRPC APIs, a managed Qdrant Cloud, and distributed mode with sharding and replication.
Weaviate
Written in Go. BM25 keyword search and hybrid fusion are built in, modules can vectorise content on ingest with external or local models, and multi-tenancy is native. GraphQL, REST and gRPC APIs, plus a managed Weaviate Cloud.
In detail
What each one is good at
Filtering inside the search
Every point carries a JSON payload. Filters on that payload are evaluated during the graph traversal, not applied to a candidate list afterwards, so selective filters do not starve results. Payload indexes make common filters cheap.
Quantisation to fit memory
Scalar, product and binary quantisation store compressed vectors in memory while the originals stay on disk for rescoring. That lets a large collection run on modest hardware. We measure recall before and after, because the right scheme depends on the embedding model.
Sparse vectors and fusion
Keyword signals are stored as sparse vectors next to dense ones, and the query API fuses the two result lists. Multiple named vectors per point let you search by text, image or title in the same collection. Embedding is done by your pipeline or an integration, which keeps the model choice in your hands.
Tenancy and operations
Tenants are separated by a payload field with an index tuned for that pattern, so one collection can hold many small tenants. Snapshots give backups, and distributed mode adds sharding and replication when one node is no longer enough.
Keyword and hybrid search built in
An inverted index gives BM25 keyword search without a second engine. A hybrid query runs keyword and vector search together and fuses them with a weighting you control. Exact codes and paraphrased questions both work from one call.
Modules that vectorise on ingest
Vectoriser modules call an external embedding API or a locally hosted model when objects are written and when queries arrive. The database owns the embedding step, which is convenient for small teams. We still pin the model and plan for re-embedding, per our embeddings strategy.
Native multi-tenancy
A collection can be declared multi-tenant, with each tenant isolated in its own shard. Tenants can be activated, deactivated and offloaded, which suits SaaS products with many customers of very different sizes.
APIs, compression and operations
GraphQL, REST and gRPC APIs with official clients. Vector compression options reduce memory for large collections. Backups to object storage, replication and horizontal scaling are available, and Weaviate Cloud takes the operations off your hands.
How a query runs
Filter, search, keyword, fuse: who handles which stage natively
Both stores run all four stages inside one request. The difference is how the keyword stage is fed. Qdrant expects sparse vectors from your pipeline; Weaviate builds its own keyword index as data arrives.
Capability
Qdrant
Weaviate
Metadata filtering
Payload filters during search, payload indexes
Property filters during search, inverted index
Hybrid keyword + vector
Sparse vectors fused in the query API
Built-in BM25 with hybrid fusion
Vectorise on ingest
Your pipeline or an integration
Built-in vectoriser modules
Multi-tenancy
Payload partitioning with a tenant index
Native tenants, one shard each
Memory compression
Scalar, product and binary quantisation
Vector compression options
Managed cloud
Qdrant Cloud
Weaviate Cloud
Self-host
Docker, Kubernetes, distributed mode
Docker, Kubernetes, replication
APIs
REST, gRPC
GraphQL, REST, gRPC
Implementation language
Rust
Go
Deciding
When we recommend which
Choose Qdrant when
Filters on rich metadata are central to every query, such as permissions, regions, dates and product lines.
Memory is the constraint and quantisation would let the collection fit on the hardware you have.
Your pipeline already produces embeddings and you want to keep the model choice outside the database.
You want a lean service with a small operational footprint and gRPC throughput.
Choose Weaviate when
Keyword search matters as much as semantic search and you want it built in, not bolted on.
A small team wants the database to handle vectorisation through modules rather than running a separate step.
You are building a SaaS product with many tenants of uneven size and need native isolation.
Your developers prefer GraphQL and schema-first collections.
Neither is wrong for most mid-sized workloads. If Postgres already holds your data and the corpus is modest, pgvector may be simpler still. If you are heading for cluster scale, read about Milvus. The selection guide puts all five side by side, and the comparison article goes deeper on trade-offs.
What we deliver
From evaluation to a store you can operate
Bake-off on your data
Both stores loaded with a sample of your corpus, your real queries and filters, recall and latency measured, a written recommendation.
Collection and payload design
Schema, payload or property indexes for the filters you will run, named vectors where needed, tenancy model and quantisation settings.
Qdrant when filtering on rich metadata is central, memory is tight and you want quantisation, or you prefer to own the embedding step. Weaviate when you want keyword search built in, vectorisation handled at ingest through modules, or native multi-tenancy. We run both against your real queries before recommending.
Do both support hybrid keyword and vector search?
Yes, in different ways. Weaviate has BM25 keyword search built in and fuses it with vector results in one hybrid query. Qdrant represents keyword signals as sparse vectors and fuses dense and sparse results in its query API. See hybrid search.
Can we self-host, and is there a managed option?
Both. Each runs under Docker or Kubernetes on your own infrastructure, and each vendor offers a managed cloud. The choice usually comes down to residency rules and whether a team is available to operate it.
What is quantisation and why does it matter here?
Quantisation stores vectors in a compressed form so more of the index fits in memory, at a small cost in precision. Both stores offer it. Qdrant exposes several schemes, which is useful for large collections on modest hardware. Our glossary entry explains the trade-off.
How do we keep tenants apart?
Weaviate has native multi-tenancy, with each tenant isolated within a collection. Qdrant partitions by a tenant field in the payload with an index tuned for that pattern. Both approaches work; we choose by tenant count and isolation requirement.
How long does an engagement take?
Three to six weeks for a production deployment with ingestion, filtering, hybrid retrieval where needed, and monitoring. Ask for a scoping call.
Ready to make AI work in production?
Tell us about your systems, your data and your constraints. We reply within one business day with a straight answer and a suggested next step.