Qdrant vs Weaviate vs pgvector – which vector DB for SME RAG?

What this is about

Qdrant, Weaviate, and pgvector are the three most-used vector databases for Retrieval-Augmented Generation (RAG) in May 2026. Each stores vectors (lists of numbers encoding semantic meaning) and answers "which texts are most similar to this vector" in milliseconds.

Qdrant is a Rust-written dedicated vector database from Berlin. Very fast, payload-based filters, HNSW indexing, gRPC and REST. Apache 2.0 licence. Weaviate is an Amsterdam open-source vector DB project with GraphQL API, built-in hybrid search modules, and multimodal support. BSD-3-Clause licence. pgvector is a Postgres extension by Andrew Kane – not a standalone server but an extension on top of the established Postgres database. PostgreSQL licence.

As of May 2026 the picture is nuanced: pgvector (version 0.9 released April 2026) has caught up surprisingly strongly at very large workloads thanks to pgvectorscale (Timescale) – at 50M vectors pgvectorscale delivers 471 QPS vs Qdrant 41 QPS at 99 percent recall. At mid-size workloads (1M vectors) Qdrant leads with 1840 QPS. Weaviate scores on multimodal and hybrid search.

Why this comparison?

When you build RAG for a Swiss SME – internal guidelines, client correspondence, client FAQ – the vector DB choice drives three consequences.

First operations effort. If you already have Postgres in the stack (which is true for 80 percent of SME setups, from Pexeos to Fairlane to Realty51), pgvector costs one CREATE EXTENSION line. Qdrant needs its own container, a volume, a backup plan. Weaviate additionally needs GraphQL know-how and a schema manager.

Second scaling limit. Up to 1 million vectors pgvector is sufficient (and usually already there). At 10 million vectors Qdrant becomes the fastest and simplest tool. From 50 million vectors pgvectorscale (Timescale extension) becomes worth it – or you distribute over multiple Qdrant nodes. Weaviate scales too but with higher operations effort.

Third feature set. If you need hybrid search (vector + full-text BM25), Weaviate has the most elegant built-in model. Qdrant supports hybrid search since version 1.10 (2025) but config-based. pgvector combined with Postgres full-text search is the most manual variant.

This comparison helps find the right DB for your data size and your stack – without falling into the "all three are the same" cliche.

Head-to-head on 6 axes

Data protection and EU hosting. All three are self-hostable on your own EU/CH infrastructure. Qdrant Cloud additionally hosts in Frankfurt; Weaviate Cloud Service hosts in EU regions; pgvector runs wherever your Postgres runs (Hetzner, Exoscale, Infomaniak). Swiss DPA compliance is a setup question, not a tool question.

Price and licence. All three are open source and free in self-host. Qdrant Apache 2.0, Weaviate BSD-3-Clause, pgvector PostgreSQL licence. Qdrant Cloud free tier 1 GB, then from USD 25/month. Weaviate Cloud from USD 25/month. pgvector as a pure extension has no own cloud variant, but every Postgres hosting provider (Supabase, Neon, Crunchy) ships pgvector by default.

Maturity / scaling. Qdrant 1840 QPS at 1M vectors (ANN-Benchmarks 2025), p99 latency about 12 ms at 10M, 10-25 percent faster than Weaviate and Milvus. Weaviate about 1400 QPS at 1M, p99 about 16 ms at 10M. pgvector classically slower at 1M (about 800 QPS) – but with pgvectorscale at 50M about 471 QPS vs Qdrant 41 QPS. Scaling profiles differ.

Lock-in. Qdrant: REST/gRPC with a clean schema, data export simple. Weaviate: GraphQL-first, data export via backup module, own schema language. pgvector: stays in Postgres, full pg_dump workflow, no lock-in beyond Postgres.

Self-host effort. pgvector easiest: one CREATE EXTENSION command in existing Postgres, done. Qdrant: one Docker container, about 1 hour setup including backup. Weaviate: one Docker container plus optional vectorizer modules (e.g. text2vec-openai) plus GraphQL schema, about 2-4 hours setup.

DACH fit. Qdrant German company (Berlin), forum in DE/EN, docs bilingual. Weaviate Dutch, EN only. pgvector international community, EN only – but Postgres itself has a large DACH community.

Decision path in 6 steps

1. 01Estimate vector volume: number of documents x average chunks per document. Under 1M = pgvector, 1-10M = Qdrant or pgvectorscale, over 10M = Qdrant cluster.
2. 02Check existing stack: Postgres already there? Then pgvector first. No Postgres, or Postgres already heavily loaded? Then Qdrant.
3. 03Check feature needs: hybrid search needed? Multimodal needed? If both, evaluate Weaviate.
4. 04Set latency requirement: under 50 ms p99 fits pgvector; under 20 ms p99 fits Qdrant.
5. 05Write backup and disaster-recovery plan: pgvector with pg_dump, Qdrant with snapshot API, Weaviate with backup module.
6. 06Build a pilot: index 5000-10000 real chunks, measure 20 real queries, document latency and relevance.

When which DB

When pgvector. You already have Postgres in your stack. Your vector volume is under 1-2 million (covers 80 percent of SME RAG cases). You want one tech stack, not two. You value simple backups, simple monitoring, a database engine every engineer knows. pgvector is the default for Swiss fiduciary, law firms, and SME RAG up to mid size. With pgvectorscale it scales surprisingly well to 100M vectors.

When Qdrant. Your vector volume exceeds 5-10 million (e.g. large document corpus, law firm with 20+ years of precedent archive). You need very low latency (under 20 ms p99). You want payload-based filters (client=X AND confidentiality=high AND date>2024). You want a clean tech stack where the vector DB does not hang off the main database. Qdrant is the default from mid-scale needs upward.

When Weaviate. You need multimodal search (text + image + audio in one index). You want hybrid search (BM25 + vector) built in, not hand-rolled. You have a team that knows and likes GraphQL. You have an e-commerce or content-discovery use case with mixed data types. Weaviate is the choice for multimodal-heavy use cases.

When NONE. If you have fewer than 10000 documents and configuration is a major load: use the in-memory variant of LangChain/LlamaIndex (FAISS-based). If you need real-time personalisation with streaming updates on 1B+ vectors (ad targeting): Vespa or Milvus are better positioned for that. If you need absolute tier-A sovereignty and offline capability: a local Qdrant in an air-gapped setup.

When NONE of the three

If you have under 10000 documents and one engineer maintaining, a vector DB is overkill. FAISS in-memory (built into LangChain/LlamaIndex) suffices; re-indexing takes seconds, no backup plan needed.

If you need 1 billion vectors or more (e.g. ad personalisation, very large recommender systems), Vespa and Milvus are better positioned – both have distributed-by-default architectures with sharding. Qdrant supports sharding since version 1.7 but Vespa has years of lead in that space.

If you want absolutely no additional database and stay very small (50 documents): store the embeddings in a Markdown or JSON file and brute-force cosine similarity at each query. Honestly, for a 50-document client FAQ that is faster and simpler than any vector DB.

If you need pure full-text search, Elasticsearch or OpenSearch is more appropriate – vector DBs become worthwhile only when semantic similarity is the key need (question in natural language, answer in documents using different wording).

Trade-offs

FAQ

Related topics

Sources

1. Qdrant – Documentation and benchmarks · 2026-05
2. Weaviate – Documentation · 2026-05
3. pgvector – GitHub repository (Andrew Kane) · 2026-05
4. Vector Database Benchmarks 2026 – pgvector 0.9, Qdrant, Weaviate, Milvus, LanceDB · 2026-04
5. pgvectorscale – Timescale extension · 2026-03