What distinguishes Qdrant from Weaviate and Milvus at a conceptual level, and what would make you choose one over the others for a given project?

All three are open-source vector databases with similar core capabilities (ANN search, filtering, metadata), but they differ in positioning and trade-offs. Qdrant is written in Rust and positions itself around performance, filter-aware search, and a focused feature set. It emphasizes payload filtering during graph traversal, quantization, and a clean operational model with a segment-based storage engine. Weaviate is written in Go and positions itself around a GraphQL-style API, modular vectorizers, and a broader feature surface including hybrid search, generative modules, and multi-tenancy. Milvus is written in Go and C++ and positions itself around scale, with a distributed architecture that supports multiple index types (including GPU-accelerated), a separate control plane, and support for very large collections. The conceptual difference is that Qdrant focuses on doing a few things very well, Weaviate focuses on a rich, integrated experience, and Milvus focuses on scale and flexibility.

The mechanism that shapes each project's strengths is its architecture. Qdrant's segment-based storage with immutable segments and a background optimizer gives it predictable write throughput and filter-aware HNSW traversal, which is the foundation of its filtering performance. Weaviate's module system lets you plug in vectorizers and generative models directly, so the database can do the embedding and the generation, which simplifies the application but couples it to the module's choices. Milvus's separation of the coordinator, the query nodes, and the data nodes gives it the flexibility to scale each component independently and to support multiple index types, but it also makes the operational model more complex. In practice, the choice is often driven by the ecosystem: if you are already using a Weaviate module, Weaviate is the natural fit; if you need extreme scale or a specific index type, Milvus is the natural fit; if you want a focused, high-performance vector database with strong filtering, Qdrant is the natural fit.

The trade-off is between focus and breadth, and between simplicity and flexibility. A focused database like Qdrant does fewer things but does them well; a broad database like Weaviate does more out of the box but may have more dependencies and configuration. A simple operational model like Qdrant's is easier to run at small scale but may be less flexible at very large scale; a distributed architecture like Milvus's is more flexible but more complex to operate. The common mistakes are: (1) choosing based on benchmarks alone without considering the operational model; (2) choosing based on the feature list without checking whether the features you need are mature; (3) not considering the ecosystem and the integrations; (4) not benchmarking with your own data and query pattern, which is the only way to know which performs best for your workload. Version note: all three projects evolve quickly, and the feature comparison shifts over time. The right approach is to define the requirements, shortlist the candidates, and benchmark the shortlisted options with your data.

Version-dependent: the feature sets and performance of all three projects evolve quickly. The comparison should be based on the current versions and benchmarked with your data. The fundamental positioning differences are more stable: Qdrant for focused performance and filtering, Weaviate for breadth and integration, Milvus for scale and flexibility.