Question presented to candidate: "We run Postgres today and are adding RAG over customer documents, with thousands of tenants. The team is split between pgvector, Pinecone and Qdrant. How would you make that decision, and what would you test before committing?"
What a strong answer should cover:
- The three are different shapes: pgvector is an extension inside the Postgres you already run (vectors next to rows, SQL filters, transactions); Pinecone is a fully managed service billed on usage; Qdrant is an open-source engine you self-host or buy as a managed cloud, with rich payload filtering and quantization
- Filtered search is the real differentiator: post-filtering a small ANN candidate list returns too few results for selective filters; know pgvector
ef_searchand the iterative index scans added in 0.8.0, Qdrant payload indexes and filter-aware HNSW with a query planner, and Pinecone filtering integrated into retrieval - Multi-tenancy design per system: Postgres row-level security, partitions or partial indexes; Pinecone namespaces; Qdrant tenant payload indexes and per-tenant graphs
- Scale and cost levers: dimension limits (pgvector HNSW
vectorup to 2,000,halfvecup to 4,000), memory and quantization, managed usage pricing versus servers you run - Operations and consistency: one database and one backup versus a second system to sync; who is on call
- A proof of concept on your own data: recall@k against exact search, p95 latency at target QPS with real filters, ingest and delete behaviour, cost at projected scale
Clarifying questions expected:
- How many vectors and tenants, how uneven are tenant sizes, and how fast does it grow?
- What latency and query rate must we meet, and how selective are the typical filters?
- Do we have the people to operate another stateful system, and are there data-residency rules?
Code / implementation expected: Optional โ explaining or sketching the filtered query (for example the pgvector SQL with an HNSW index and iterative scan) and a recall measurement is a strong signal.