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

Match pairs·Medium·4.0 · 0·~2 min·Asked atBcg Dify Fireworks Ai

Attempt it

Drag each answer to line up with its matching prompt

Document upserted seconds ago is missing from results

Post-filtering pruning an already small ANN candidate list

Recall sagging after a bulk delete, latency unchanged

Freshness lag: the write sits in a buffer or segment not yet searchable

Identical query returns different results run to run

Different distance metrics or normalization conventions per collection

Similarity scores from two collections are not comparable

Replicas or segments answering nondeterministically with different ANN candidate sets

Filtered queries return fewer than k results despite many matches

Tombstones: deleted nodes still occupy and pollute graph traversal

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.

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

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.

Triage in vector databases is largely pattern recognition. The same five symptoms appear across Pinecone, Milvus, Qdrant, Weaviate, Vespa, and self-hosted Faiss deployments, and each one points at a specific structural property of how vector indexes are built. Teams that recognize the patterns debug in minutes; teams that do not can spend days chasing the wrong layer.

This deep dive treats the five symptoms in the question as a triage map. For each one, the goal is to leave the reader with the underlying mechanism, the engine-specific surface where it shows up, and the diagnostic step that confirms the cause before the team reaches for a fix.

Freshness lag and asynchronous write visibility

Vector databases distinguish acknowledged writes from searchable writes. A write commits to a write-ahead log and a memtable, returns success to the client, and becomes searchable only on the next refresh or segment flush. The window between acknowledged and searchable is the freshness lag.

Pinecone serverless documents this as eventual consistency with sub-second to multi-second freshness depending on tier and load. Elasticsearch exposes a per-index refresh_interval (default 1s, often raised to 30s under heavy write load to reduce IO). Milvus offers per-query consistency levels (Strong, Bounded, Session, Eventually), where Strong forces a wait until the latest write is visible.

The diagnostic pattern is to query the document with a stronger consistency level or to wait the documented window and retry. If the document appears after the window, freshness lag is confirmed. If it never appears, the symptom is something else (write failed, wrong index, wrong filter).

The wrong fix is to file a data-loss bug. The right fix is to choose the consistency level that matches the user expectation: Strong for read-after-write paths (search-for-just-uploaded), Eventually for cross-user search where small delays are acceptable.

Tombstones and graph index hygiene

Replica nondeterminism and approximate search

Metric mismatch and post-filter pruning

How experienced operators diagnose VDB symptoms in 2026

Situations where this technique stops working.

2–4 min · Everything important, quickly.

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

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.

Tombstones inflate the apparent candidate count during ANN walk, but the post-filter step still rejects them. Result: the engine looks like it searched a healthy candidate set, but most candidates were dead and the filter passed only a few live ones. Compact first, then re-measure.

1 more follow-up an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases 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 bullets to scan on the way to the call.

How asynchronous write visibility creates freshness lag and how engines expose it
Why tombstones live in graph indexes and what symptoms they create

Primary sources. Browse if you want the original framing.