Vector Database Interview Guide: Indexing, Hybrid Search, and Platform Trade-offs

Vector database interviews test whether you understand approximate nearest neighbor trade-offs in production, not whether you can name vendors. Interviewers probe HNSW ef_construction and ef_search tuning, recall-latency curves, and what happens when your index outgrows single-node memory.

Hybrid search—combining dense vectors with BM25—is the default in enterprise retrieval. Candidates should explain score fusion strategies, when to rerank after fusion, and how metadata pre-filtering interacts with ANN graphs. Bad filter ordering can exclude correct results or force full scans that negate index benefits.

Platform selection is a systems decision. pgvector simplifies ops when you already run Postgres and need transactional metadata; dedicated vector stores offer better ANN tooling and multi-tenancy features at scale. Discuss migration paths, backup semantics, and whether your team can operate another datastore.

Multi-tenancy and isolation appear constantly. Interviewers ask about namespace design, per-tenant quotas, hot partitions, and ACL enforcement at query time. A vector DB that returns great global recall but leaks cross-tenant neighbors is a production incident waiting to happen.

Observability for vector search includes query latency histograms, recall proxies, index build duration, and compaction behavior. Describe how you would debug a sudden p99 spike—is it graph degradation, shard imbalance, or a query pattern shift toward adversarially long embeddings?