Choosing a vector database isn't choosing "which one is fastest" -- it's choosing which operational trade-off you're willing to accept between raw performance, simplicity, and what already runs in your stack.
All three options solve approximate nearest neighbor (ANN) search over embedding vectors, typically using variants of the HNSW (Hierarchical Navigable Small World) algorithm. The real difference isn't in the base algorithm -- it's in the operational model: pgvector is an extension on a relational database you already know, Qdrant is a dedicated vector database written in Rust built for raw performance, and Weaviate is a vector database with more integrated "full search stack" features (generation modules, classification, native multi-tenancy).
pgvector is a PostgreSQL extension that adds a `vector` data type and distance operators (cosine, L2, inner product) with HNSW or IVFFlat indexes. Its decisive advantage is operational: if you already run PostgreSQL in production, you add vector search without introducing a new system to back up, monitor, and maintain separately. You can join relational metadata and vector search in the same SQL query, something that requires duplicating data or making separate calls in a dedicated vector database.
The real limitation shows up at scale: pgvector wasn't designed from the ground up for massive vector search, and on collections of tens of millions of vectors with strict latency requirements, its performance tends to lag Qdrant in throughput benchmarks under high concurrent load, especially when complex filters get combined with vector search.
Qdrant is written in Rust and designed from scratch exclusively for vector search, which shows in throughput and latency benchmarks under load -- consistently among the fastest open source options in independent comparisons (ANN-Benchmarks and community evaluations). Its filtering system (pre-filtering combined with the HNSW graph, not naive post-filtering) solves a classic vector search problem well: filtering by metadata without drastically degrading result quality or performance, something many simpler implementations handle poorly.
It supports vector quantization (scalar, binary, product) to reduce memory footprint on large collections, and has good multitenancy support via payload-based sharding.
The cost is operational: it's one more system to deploy, back up, and monitor, separate from your main database.
Weaviate positions itself more as a complete search platform than a pure vector database. It includes built-in modules to automatically generate embeddings (you don't need to generate the vector externally and pass it in), native hybrid search (BM25 + vector) with configurable result fusion, and multi-tenancy support designed from the core for SaaS with strong per-tenant isolation.
Its schema model (with typed classes and properties, similar to GraphQL) gives more structure than Qdrant, which helps in projects with stricter data governance requirements, but adds an extra configuration layer for simple use cases.
Public "vectors per second" benchmarks are useful but misleading in isolation -- real performance depends a lot on your vectors' dimensionality, your read-vs-write ratio, whether you need simultaneous complex filtering, and your memory budget for keeping the full HNSW index in RAM (critical for latency across all these solutions). In projects where we've done this evaluation for clients, the variable that moves the decision most isn't raw speed but the operational cost of maintaining one more system versus leveraging existing PostgreSQL.
If you already run PostgreSQL and your scale is hundreds of thousands to a few million vectors, start with pgvector -- the operational simplicity of one less system to maintain almost always outweighs the marginal performance gain of a dedicated solution at that scale. If your scale exceeds 10-50 million vectors, you need strict p99 latency under high concurrent load, or constant complex filtering, Qdrant is the more solid technical option due to its performance-first design. If you need a more complete search platform with integrated embedding generation and native SaaS multitenancy from day one, Weaviate reduces integration work in exchange for accepting its more opinionated schema model.
Carlos Montiel is an enterprise AI solutions architect. He implements LLMs, Agents, RAG, and orchestrators for companies across Guatemala and Latin America. Reach out for a consultation.
Contact Carlos Montiel