pgvector vs Qdrant

pgvector and Qdrant offer two answers to "where should embeddings live?" — alongside your relational data in Postgres, or in a dedicated Rust-built vector engine. They appeal to different teams.

Where pgvector wins

• One database, one backup, one auth story. Vectors next to users, documents, and audit logs. ACID transactions and joins work as expected.

• Row-level security enforces multi-tenancy in the database. Qdrant scopes by payload filters or shard keys — both work, but enforcement is application-side.

• Available on every managed Postgres. Supabase, Neon, RDS, Cloud SQL, Crunchy Bridge. No new vendor relationship needed.

Where Qdrant wins

• Payload-aware query planner. Qdrant indexes payload fields and lets filter selectivity drive the plan. pgvector relies on Postgres's general planner, which is not vector-aware.

• Higher throughput per core at steady-state. Rust engine purpose-built for vector workloads; pgvector inherits Postgres's general-purpose tradeoffs.

• First-party MCP server. mcp-server-qdrant ships out of the box. pgvector relies on community wrappers.

• Hybrid retrieval with dense + sparse + late interaction. Built into the engine. pgvector hybrid is hand-built with tsvector.

The agentic difference

For agents already reading and writing Postgres data, pgvector keeps retrieval inside the same transactional and RLS-enforced boundary. For agents whose retrieval workload is large, filter-heavy, or latency-critical, Qdrant's purpose-built planner and Rust performance deliver consistently lower p99 latency. Qdrant's first-party MCP server is a real advantage for agent integration today.

When to pick which

• Pick pgvector when Postgres is already the operational store and you want vectors inside the same database, backup, and security model.

• Pick Qdrant when filter-heavy queries dominate, performance matters, or you need a first-party MCP server.