Match each production search symptom to its most likely vector database root cause.

Match pairs·Medium·4.0 · 0·~2 min

Attempt it

Document upserted seconds ago is missing from results

Recall sagging after a bulk delete, latency unchanged

Identical query returns different results run to run

Similarity scores from two collections are not comparable

Filtered queries return fewer than k results despite many matches

Production vector search has a handful of canonical failure modes. Each symptom maps to a specific layer of the system. **Missing fresh document** points at the write path. Most engines acknowledge a write before it is searchable; the document sits in a memtable or fresh segment until the next flush. The fix is to query the right consistency tier or wait for the flush window. **Recall sag after bulk delete** points at tombstones. Deleted nodes still occupy graph memory and still get visited during traversal. The fix is to run compaction or rebuild the affected shards. **Run-to-run nondeterminism** points at the read path. Multiple replicas or shards are answering, and their ANN candidate sets differ slightly. The fix is either deterministic routing or accepting that ANN is approximate and pinning the user to a session-stable replica. **Incomparable scores across collections** points at config. Different distance metrics (cosine vs dot product vs L2) or different normalization conventions produce numbers that look similar but mean different things. **Filtered results below k** points at post-filtering. The ANN layer returned a fixed candidate count, then the filter rejected most of them. The fix is pre-filtering (push the filter into the search) or oversampling.

These five symptoms are the canonical vector-search incident set. Each maps to a specific structural feature. **Freshness lag.** Vector engines split write ack from visibility. Writes commit to a WAL or memtable, ack, then become searchable on the next refresh. Pinecone, Elasticsearch, Milvus expose this as a refresh interval or consistency level. Fix: query with the right consistency level or wait the refresh window. **Tombstones.** HNSW and graph-based indexes mark deleted nodes rather than removing them. The dead nodes still occupy memory and still get walked during search, polluting the candidate set and slowing traversal. Recall sags in heavily churned regions and memory does not shrink after deletes. Compaction or full rebuild reclaims the space. **Replica nondeterminism.** ANN is approximate; different replicas with slightly different segment layouts will return candidate sets that overlap but do not match exactly. Run-to-run differences across a replicated cluster are expected, not a bug. The fix is either to accept it as a property of the system, pin sessions to a single replica, or set deterministic routing parameters where the engine supports it. **Metric mismatch.** Cosine returns values in `[-1, 1]`, dot product can return any real number, and L2 distance is unbounded. Two collections with different metrics or different normalization conventions cannot have their scores compared directly. The fix is to standardize the metric or convert via a known relationship before comparing. **Post-filter pruning.** Post-filtering runs the ANN search first, then applies the filter to the candidates. If the candidate set is `k = 50` and the filter passes only 10% of vectors, the user gets 5 results instead of 50.

Quick reference

TL;DR

Freshness lag, tombstones, replica nondeterminism, metric mismatch, and post-filter pruning are the five canonical vector-search incidents. Each symptom maps to a specific layer in the index.

Memory aid

Easy to grasp

Think of a vector database as a library with several rooms. If a brand-new book is missing, somebody is still wheeling it from the truck. If old books mysteriously slow things down even after a purge, the librarians left empty cards on the shelves. If two friends ask the same question and get different answers, they walked into different rooms. If two libraries rate the same book differently, they grade on different scales. If a request for ten Spanish books gives you three, the library only checked a small shelf before filtering by language. Each symptom points at a specific layer of how the search is built, and matching the symptom to the layer is half the debugging job.

Key concepts

Vector Databases

Detailed answer & concept explanation

~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.

Quick scan · 2–4 min

Everything important, quickly.

6 minutes: walk each of the five symptoms, name the layer it points to, give the engine-specific mechanism, and finish with the triage dashboard that surfaces them proactively.

Real-world examples

Real products, models, and research that use this idea.

Pinecone serverless documents eventual consistency and provides freshness latency metrics so teams can debug missing-write symptoms without guessing
Qdrant exposes payload pre-filtering as a first-class feature precisely so users avoid the post-filter pruning trap on selective filters
Milvus offers explicit consistency levels (Strong, Bounded, Session, Eventually) so read-after-write paths can opt into stronger guarantees
Weaviate runs background compaction on its HNSW segments and emits tombstone-ratio metrics so operators can tune the cadence

Interviewer follow-ups

What an interviewer would ask next. Try answering before peeking at the approach.

QTwo of these symptoms can interact: filtered queries returning below k just after a bulk delete. Diagnose.

QHow would you build a triage dashboard that surfaces these five symptoms before users complain?

Don't say this

Red flags and common mistakes that signal junior thinking. Click to expand.

Most common mistake

Treating these as unrelated bugs. They are the canonical incident set, and each one maps to a specific structural feature of the index: write buffering, tombstone semantics, replica state, metric config, filter ordering.

60-second cheat sheet

The night-before-the-interview bullets. Scan these on the way to the call.

References

Primary sources. Skim if you want the original framing.