EthosPowerAI
The question every search project reaches
Every document search project reaches the same point. The documents are split into chunks and the embeddings are computed. Now someone has to choose the vector database that will hold them. The three names that come up are Qdrant, Weaviate and Milvus.
My comparison rests on two kinds of evidence, and you should keep them apart. Qdrant runs under this site's search and under the Second Brain pattern, and has been in production since 2024. What I say about it is first-hand. I have run Weaviate and Milvus only to evaluate them. What I say about those two comes from their documentation, their published benchmarks and the way they are deployed, so weigh it accordingly.
Five things worth comparing
The benchmark charts do not show what decides a deployment. Query latency matters. So do four other things: how many processes you must restart on a Tuesday morning, whether the filtering you need is a built-in feature or a workaround, what it costs to move away later, and whether one engineer can run the database without a second one on call. The synthetic benchmarks are easy to find and mostly agree with each other. The three databases differ on the operational questions.
Qdrant, the one I run
Qdrant is written in Rust and ships as a single binary or one container. It has needed nothing from me since the day I installed it. The published p99 latencies are in the low single-digit milliseconds for collections under a few hundred million vectors. That matches what I see on a store far smaller than that. The whole configuration fits in a file I can read at a glance.
Its main strength is filtering. Named vectors and payload filters are part of the query, not a step that runs afterwards. A search that must be limited to a tenant, a date range or a document type is limited first, and the similarity search then runs only on what is left. I build search systems in which a client's documents must never cross from one workspace to another. For that work, filtering is the feature that decides the choice.
Weaviate, when the data is not just text
Weaviate is the choice for multi-modal search. When a query must cover text, images and structured fields at once, its module system and GraphQL interface do the joining. Otherwise you would write that joining as application code. This is a real capability.
The cost is more moving parts. Weaviate is a Go service with more configuration than Qdrant. Its documentation quotes latencies of roughly eight to fifteen milliseconds in production-style setups. The GraphQL interface can express a great deal, and the third developer on a project will need the manual to use it. For most search over documents it is more database than the job needs.
Milvus, when the vectors are counted in billions
Milvus is built for a scale that almost nobody reading this has: billions of vectors, GPU-accelerated indexes and a distributed cluster. Its performance ceiling is the highest of the three, and its own benchmarks show it. The architecture that reaches that ceiling uses etcd for metadata, MinIO for objects and Pulsar for the log. A multi-node deployment is therefore the normal case. A team with dedicated infrastructure engineers can run that. A team of one should not start there, and neither should a client whose compliance team wants to understand every process on the server.
The verdict
Choose Qdrant for self-hosted search under a few hundred million vectors, especially where every query filters by tenant or document type. It is what I run, and it is what I would install for a client on Monday. Choose Weaviate when the search really is multi-modal and the team can manage the extra parts. Choose Milvus when the collection is measured in billions and someone is paid to operate a cluster. For most teams the first answer is the right one. The scale that justifies the other two arrives later, if it arrives at all.
The search stack I run, with its diagrams, is on the open-source stack page.