Qdrant vs pgvector

Both store embeddings and find the nearest ones to a query, and both use HNSW indexes to do it fast. For a few hundred thousand vectors with simple filters, either will answer in milliseconds, and users will not tell them apart.

The real choice is architectural. pgvector keeps vectors inside Postgres, so they live next to your users, documents, and permissions, and one transaction can update all of them. Qdrant is a separate service built only for vector search, so you get more search features and tuning, and one more system to run and keep in sync.

Pick pgvector when you already run Postgres. There is no new service, no second backup plan, and no sync job between your records and your vectors. If a document is deleted, its embeddings can be deleted in the same transaction.

Pick it when the search needs your relational data. Filtering by tenant, date, or status, or joining to other tables and extensions such as PostGIS, is plain SQL.

And pick it when the collection is moderate and the team is small. Managed Postgres providers such as Supabase and Cloud SQL offer pgvector, so the vector store comes with the database you already pay for.

Pick Qdrant when vector search is the product's core workload. Large collections, many queries per second, and frequent re-indexing are what a dedicated engine is built for, and keeping that load off your main database protects everything else.

Pick it when filtering is heavy. Qdrant applies payload filters during the search rather than before or after it, which keeps results accurate when a filter, such as one user's documents, matches only a small slice of the collection.

And pick it when you need search features beyond nearest neighbours: sparse and dense vectors together for hybrid search, quantization to cut memory, and multitenancy patterns built into the engine.

Most RAG systems never search everything. They search one user's notes, one customer's documents, or one project's files. How the store combines the filter with the vector index decides whether results are both fast and complete.

In Qdrant, you index the payload fields you filter on and the engine plans around them. In pgvector, an approximate index can return fewer rows than you asked for when a selective WHERE clause discards most of the candidates, so you test filtered queries on realistic data and tune the index and query settings, or use partitions or partial indexes per tenant.

Embeddings are portable. If you keep the source text and the embedding model's name with each chunk, you can move from pgvector to Qdrant, or back, with a re-index job rather than a rewrite. Hide the vector store behind one module in your code and the switch touches one file.

That is why we rarely agonise over this choice on a first version. Start where your data already lives, measure retrieval quality and latency with real queries, and move when the numbers say so.