pgvector or Qdrant: Which vector database for your RAG?

A RAG or semantic search project stores embeddings, vectors, and finds those closest to a query. Two options stand out: pgvector, a PostgreSQL extension, and Qdrant, a dedicated vector database. The right choice depends on your data volume and stack.

pgvector: a single database for everything

pgvector adds vector type and similarity search directly to PostgreSQL. Your embeddings live alongside your business data, in the same database, often Supabase.

• A single database to manage, back up, and secure.
• Your vectors and relational data intersect in a single SQL query.
• Hostable in Europe or self-hosted, just like the rest of your PostgreSQL.

For the vast majority of projects, from a few hundred thousand to a few million vectors, pgvector is more than sufficient. It’s our default choice, as detailed on our Supabase agency page.

One technical limit deserves checking before deciding, because it usually surprises people at index creation time. pgvector offers two approximate index types, HNSW, faster to query but slower and hungrier to build, and IVFFlat, the reverse. But the vector type is only indexable up to 2,000 dimensions; halfvec, in half precision, goes to 4,000. A 3,072-dimension embedding, a common size with current providers, therefore cannot be indexed directly: you have to switch to half precision, reduce dimensionality at generation time, or index subvectors. That is a one-line SQL matter when you know it, and an afternoon lost when you discover it.

Qdrant: the dedicated database for very large volumes

Qdrant is designed solely for vectors. At very large scale (tens of millions of vectors, critical latency, complex metadata filtering), a dedicated database handles the load better and offers advanced filtering and quantization features. The trade-off: an additional component to manage alongside your PostgreSQL.

What Qdrant brings at that scale is mostly about memory. Quantization, scalar, binary or product, sharply reduces the RAM footprint of vectors, at the cost of a precision loss recovered by rescoring the best candidates against the original vectors. That is what makes an index of tens of millions of vectors viable on a reasonable machine. At a few hundred thousand vectors the mechanism buys you nothing: which is precisely the boundary between the two approaches.

How to choose

• pgvector if your volume is manageable and you want a simple stack, which covers most business cases.
• Qdrant (or a dedicated alternative) if you're targeting very high volume, tight latency, or advanced filtering.

In both cases, the real challenge remains the RAG architecture: chunking, embedding quality, and result filtering. We cover this in our article on RAG in enterprise, and it’s at the core of our AI assistants connected to your data.

That point deserves underlining, because it decides perceived quality far more than the engine does. A RAG system is judged on two measurements, not on an impression: recall, is the right answer among the retrieved passages?, and faithfulness, meaning the share of statements not supported by those passages. Vectara’s public leaderboard measures exactly that second dimension on a faithful-summarisation task; the best models still sit at a few percent hallucination, which is not zero. Fifty hand-annotated questions on your own documents tell you more than any vector-database comparison.

A semantic search project to scale? We’ll help you pick the right database.