--- title: Vector Database Interview Questions (2026 Guide) description: Vector database interview questions and answers — embeddings, HNSW and IVF indexes, recall vs latency, metadata filtering, hybrid search and scaling tradeoffs. url: https://usegreenroom.app/blog/vector-database-interview-questions last_updated: 2026-08-01 --- ← Back to blog Technical · AI # Vector database interview questions and answers August 1, 2026 · 12 min read ![Vector database interview questions and answers — guide cover from Greenroom, the AI mock interviewer](/assets/blog/vector-database-interview-questions-hero.webp) The search worked beautifully in testing. In production, users filtering by their own department got three results instead of twenty, and sometimes zero, and the team spent two weeks assuming the embeddings were bad. They were fine. The system was fetching the top 20 nearest vectors globally and *then* applying the department filter, so nineteen of them were thrown away after the fact. That bug is the most common real failure in vector search, and it is why **vector database interview questions** are really information retrieval questions. Anyone can insert vectors and call a similarity search; what interviewers probe is whether you understand approximate indexes, the recall-latency trade, and filtering. This guide covers the six areas that recur. ## Embeddings and distance metrics - **What a vector index stores.** Dense float vectors produced by an embedding model, plus an identifier and usually metadata. The database's job is to find the nearest vectors to a query vector, fast, across millions of them. - **Distance metrics.** Cosine similarity measures angle and ignores magnitude; dot product includes magnitude; Euclidean (L2) measures straight-line distance. The rule that matters: **use the metric the embedding model was trained with.** Using cosine on a model trained for dot product quietly degrades results without any error. - **Normalisation.** On normalised vectors, cosine and dot product produce the same ranking, and L2 becomes monotonically related to both. Being able to say that cleanly is a good signal. - **Dimensionality.** Higher dimensions cost memory and latency linearly and improve quality with diminishing returns. Matryoshka-style embeddings that can be truncated are worth knowing about. ![Diagram of vector database interview topics — embeddings and distance metrics, index types, recall versus latency tuning, metadata filtering, hybrid search and operational concerns](/assets/blog/vector-database-interview-questions-diagram.webp) Six areas. The one candidates skip is filtering, which is where most production vector systems actually go wrong. ## Index types, and why exact search loses **"Why not just compute the distance to every vector?"** For a small corpus you should — a flat index gives perfect recall and is often the right answer under roughly a hundred thousand vectors. Beyond that, brute force is linear in corpus size and the latency becomes unacceptable, which is why approximate nearest neighbour indexes exist. The trade is explicit: **you give up guaranteed correctness for speed.** Saying that sentence out loud early is what marks a candidate who understands the field. - **HNSW** — a navigable small-world graph in layers. Excellent recall and latency, high memory use, and slower to build. The common default. Tuning knobs: `M` (connections per node, driving memory and quality) and `efConstruction` at build time, `efSearch` at query time to trade latency for recall. - **IVF** — partitions vectors into clusters, searches only the nearest few. Lower memory, needs a training step, and quality depends on `nprobe`, the number of clusters searched. Points near a cluster boundary can be missed. - **Product quantisation** — compresses vectors into codes, cutting memory dramatically at some accuracy cost. Usually combined with IVF for very large corpora. - **DiskANN and similar** — for corpora too large for RAM, trading latency to keep most of the index on SSD. The framing interviewers want: choose based on corpus size, memory budget, update frequency and required recall — not on which one is fashionable. ## Recall versus latency **"How do you measure recall?"** This is the question that finds people out. You compute ground truth with an exact brute-force search over a sample of queries, then measure what fraction of the true top-k your approximate index returns. Without that measurement you are tuning blind, and most teams never build it. Then the tuning conversation: raising `efSearch` or `nprobe` increases recall and latency together; the right operating point comes from the product requirement, not from a default. And note that recall at the index level is not the same as answer quality — a RAG system can have 95% recall and still answer badly if chunking is wrong. Our [RAG interview questions](/blog/rag-interview-questions) guide covers that layer. ## Metadata filtering, where systems actually break The opening story. Three strategies: - **Post-filtering** — retrieve top-k by vector similarity, then apply the filter. Simple, and it returns too few results whenever the filter is selective. This is the default in naive implementations and the source of the bug. - **Pre-filtering** — restrict the candidate set to matching vectors first, then search within it. Correct, but a brute-force pre-filter loses the index's benefit unless the database supports filtered traversal. - **Filtered ANN traversal** — the index walk itself respects the filter. What good vector databases implement, and the answer to give. Also worth mentioning: over-fetching as a pragmatic mitigation (retrieve 200, filter, keep 20), and that permission filters must be applied here rather than downstream, because a permission bug in a retrieval system is a data leak. ## Hybrid search Dense vectors capture semantics and miss exact tokens — product codes, error codes, names, version numbers. A user searching for a literal SKU wants a literal match. The standard answer is hybrid: run dense retrieval and a keyword method such as BM25, then fuse the ranked lists, commonly with reciprocal rank fusion because it does not require the two score scales to be comparable. Be able to explain why score normalisation across two different retrieval systems is awkward, which is exactly why rank-based fusion is popular. Our [Elasticsearch interview questions](/blog/elasticsearch-interview-questions) guide covers the keyword half. ## Operations and scaling - **Updates and deletes.** Graph indexes such as HNSW handle deletes with tombstones and degrade over time, requiring periodic rebuilds. Interviewers like this question because it separates people who have run one from people who have demoed one. - **Re-embedding.** Changing the embedding model means re-embedding and re-indexing the entire corpus, usually with a dual-write or blue-green index swap so search stays up. - **Sharding.** Partition by tenant or by a metadata key rather than randomly, so a filtered query touches fewer shards. - **Memory is the binding constraint.** Estimate it out loud: dimensions times four bytes times vector count, plus graph overhead for HNSW. Ten million 768-dimension vectors is roughly 30GB before the index structure, and that arithmetic is a very good thing to volunteer. - **Caching.** Frequent queries and their embeddings, since embedding the query is itself a network call in most architectures. - **Cost per query.** Embedding call plus search plus any reranking, at expected QPS. ## Choosing a vector database Expect "which would you use and why", and answer on requirements rather than brand: pgvector when your data is already in Postgres and the corpus is moderate, since one fewer system is a real advantage; a dedicated store such as Qdrant, Weaviate, Milvus or Pinecone when you need scale, filtered traversal or managed operations; Elasticsearch or OpenSearch when you need hybrid search and already run them; FAISS as a library rather than a database when you control the serving layer yourself. The strongest version of this answer names the requirement that would change your mind. **The core truth:** a vector database interview is an information retrieval interview. Every good answer names a trade — recall against latency, memory against accuracy, freshness against index stability — rather than describing a feature. ## Where each prep option actually helps - **The HNSW paper, or a good summary of it** — enough to explain the layered graph and what `M` and `efSearch` do. - **The pgvector and Qdrant documentation** — both are unusually clear about filtering strategies, which is the highest-value topic here. - **Build a small index and measure recall** — computing ground truth once teaches more than any amount of reading. - **The FAISS wiki** — the best free reference on index selection by corpus size. - **ChatGPT** — good for explaining index internals. It will not notice that your design post-filters, which is the bug that actually ships. - **Greenroom** — the spoken layer. [Ari, the AI interviewer](/) runs AI-infrastructure rounds out loud and asks how you would measure it. Honest tradeoff: Ari will not benchmark your index, so do that yourself. ## Frequently asked questions ### What is a vector database and how is it different from a normal database? A vector database stores dense embedding vectors alongside identifiers and metadata, and its primary operation is finding the nearest vectors to a query vector by a distance metric rather than matching exact values or ranges. The hard part is doing that across millions of vectors quickly, which requires approximate nearest neighbour indexes that trade guaranteed correctness for speed — a trade a conventional database index does not make. ### What is the difference between HNSW and IVF indexes? HNSW builds a layered navigable small-world graph, giving excellent recall and latency at the cost of high memory use and slower index construction, tuned with M for connections per node and efSearch at query time. IVF partitions vectors into clusters and searches only the nearest few, using much less memory but requiring a training step and risking missed results for points near cluster boundaries, tuned with nprobe. Choose based on corpus size, memory budget, update frequency and required recall. ### Which distance metric should you use for embeddings? Use the metric the embedding model was trained with — usually cosine similarity or dot product — because using the wrong one degrades results silently with no error. Cosine measures angle and ignores magnitude, dot product includes magnitude, and Euclidean measures straight-line distance. On normalised vectors cosine and dot product produce identical rankings and L2 is monotonically related to both, which is why normalisation is so common. ### What is the difference between pre-filtering and post-filtering in vector search? Post-filtering retrieves the top k by vector similarity and then applies the metadata filter, which silently returns too few results whenever the filter is selective — a query filtered to one department can return three results instead of twenty. Pre-filtering restricts the candidate set first, which is correct but can lose the index's benefit if implemented as brute force. The best answer is filtered traversal, where the index walk itself respects the filter, plus over-fetching as a pragmatic mitigation. ### How do you measure recall in a vector search system? Compute ground truth with an exact brute-force search over a sample of representative queries, then measure what fraction of the true top-k your approximate index actually returns. Without that measurement you are tuning efSearch or nprobe blind. It is also worth noting that index-level recall is not the same as answer quality, since a retrieval-augmented system can have high recall and still answer badly because of poor chunking or ranking. ### How much memory does a vector index need? Estimate it as dimensions times four bytes per float times the number of vectors, plus index structure overhead, which is substantial for graph indexes such as HNSW. Ten million vectors at 768 dimensions is roughly 30GB of raw vectors before the graph itself. Product quantisation compresses vectors into codes and cuts this dramatically at some accuracy cost, and disk-based indexes trade latency to keep most of the structure off RAM. AI-infrastructure rounds reward whoever names the trade out loud. [Greenroom](https://usegreenroom.app/) runs those rounds with Ari, who asks how you would measure it. Free to start. Curious how it works? See [how AI mock interviews work](/blog/ai-mock-interview).