Identify the workload pattern where a traditional ANN-indexed vector database is the wrong tool, and a log-structured or batch-rebuild approach fits better.

MCQ·Hard·4.0 · 0·~1 min·Asked atQdrant·Relevant atCursor Databricks Turbopuffer

Attempt it

ANN indexes were designed for a specific workload shape: a corpus that changes slowly and is queried often. The mathematics of HNSW and IVF both assume that the index structure (the graph, the centroids) reflects the current data distribution; modest updates can be absorbed, extreme updates cannot. **HNSW's failure mode under extreme writes.** HNSW does not physically remove deleted vectors; it sets a tombstone bit and lets the node sit in the graph until a compaction job removes it. Under a billion writes per day workload, tombstones accumulate faster than compaction can reclaim them. The graph bloats, query latency drifts up, and (worst of all) recall silently degrades because new inserts pick neighbors from a graph polluted with stale nodes. **IVF's failure mode under extreme writes.** IVF partitions the corpus into clusters using k-means at build time. Each cluster has a centroid; queries scan the nearest few centroids' clusters. When the data distribution changes, the centroids no longer reflect the live data; queries probe the wrong clusters; recall drops. Re-clustering is expensive and cannot run continuously at extreme write rates. **The right architecture is log-structured.** Treat writes as an append-only log. Serve queries against the most recent window by brute force (Flat search), which has no index to maintain and absorbs writes for free. On a periodic schedule (every few hours or daily), batch-rebuild the ANN index from a frozen snapshot of the log. Queries fan out to both the brute force recent window and the ANN index over older data, then merge the results. This is the architectural pattern Marqo's segment design and LanceDB's incremental dataset model both implement. **Why the other options are wrong.** A million static documents indexed once is exactly what ANN was designed for. A hundred million read-heavy vectors with weekly batch upserts is standard managed vendor territory. A recall target of 0.95 is comfortably achievable with proper ANN tuning; the target does not rule out ANN.

**ANN indexes are read-heavy, modest write systems by design.** Both major families assume the index structure reflects the current data distribution and can be repaired periodically; under extreme write loads neither assumption holds. **HNSW's churn failure.** Standard HNSW handles deletes by setting a tombstone bit on the node. The node stays in the graph; queries still traverse through it; results filter it out. At modest write rates this is fine and periodic compaction reclaims tombstones. At billions of writes per day with seconds fresh visibility, tombstones accumulate faster than compaction can reclaim them. Three things drift: memory bloat (dead nodes still cost RAM), latency drift (traversal visits dead nodes), and (silently) recall degradation because new nodes pick neighbors from a graph polluted with tombstoned neighborhoods. The recall drop is the most insidious failure because it is invisible to standard monitoring. **IVF's drift failure.** IVF partitions the corpus into `nlist` clusters using k-means at build time. Each cluster has a centroid; queries scan the `nprobe` nearest centroids' clusters. When the live data distribution changes (which it does under any heavy write workload), the centroids no longer represent the data; queries probe clusters that no longer contain the relevant vectors; recall drops. Re-clustering would fix this but is an expensive batch operation that cannot run continuously at billion writes per day rates. **The right architecture: log-structured ingest plus batch ANN.** Treat writes as an append-only log. Serve queries against the most recent window (last few minutes to hours) by brute force over the log; Flat search has no index to maintain and absorbs writes at the cost of linear scan over a small recent window. On a periodic schedule (every few hours, or daily), build a fresh ANN index from a frozen snapshot of the log.

Quick reference

TL;DR

ANN indexes break under billions of writes per day with seconds fresh visibility. HNSW tombstones accumulate, IVF centroids drift.

Memory aid

Easy to grasp

Imagine an enormous library where the librarians spend most of their time carefully placing books on the right shelves so you can find any book in seconds. Now imagine someone keeps shipping in truckloads of new books every minute. The librarians cannot keep up; the shelf order falls apart; queries get slow and miss books. The honest fix is to stop pretending the library can absorb live truckloads. Stack the new books on the loading dock (the log), serve recent queries by scanning the dock, and once a day shut down briefly to re-shelve everything onto the proper shelves (the batch rebuild). Vector databases work the same way under extreme write loads.

Key concepts

Write patterns

Detailed answer & concept explanation

~6 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.

5 min: ANN's read-heavy design assumption, HNSW's tombstone failure mode under extreme writes, IVF's centroid drift failure mode, the silent recall degradation, the log-structured + batch ANN rebuild pattern with brute force recent window, and why the other options describe correct ANN territory.

Side-by-side

Workload	Right architecture	Why
1M static docs, low QPS	Single HNSW or IVF index	Original ANN use case; modest update rate
100M reads, weekly batch upserts	Managed vector DB with periodic compaction	Upsert cadence within compaction window
Billions of writes/day, seconds fresh	Log-structured ingest + batch ANN rebuild	ANN maintenance cannot keep up at this rate
10M vectors, recall ≥ 0.95	HNSW with high ef_search OR IVF with high nprobe	Recall target is tunable, not a hard wall

Real-world examples

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

Marqo's segment based architecture treats writes as appends to new segments and merges segments in the background, which scales much better than monolithic HNSW under heavy writes.
LanceDB's incremental dataset model lets writers append new fragments without rebuilding the full index; periodic compaction merges fragments and updates the index.
The Big-ANN-Benchmarks streaming track (NeurIPS competition) specifically measures vector indexes under continuous upserts plus queries, surfacing the failure modes that static benchmarks miss.
Pinecone's continuous background optimization runs precisely to keep up with moderate write rates; at extreme rates the architecture would need explicit log-structured ingest, which is why Pinecone's billion-scale deployments are not write-heavy.
Milvus's segment based architecture (sealed segments are immutable, compaction merges them in the background) is the closest thing in the managed vector DB world to the log-structured pattern; it handles heavy writes much better than monolithic HNSW does.

Interviewer follow-ups

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

QHow does FreshDiskANN extend Vamana to handle streaming inserts and deletes?

QWhat is the latency cost of fanning out a query to both the brute force recent window and the batch ANN surface?

QWhen would you use a Vamana based engine like DiskANN instead of the log-structured pattern?

Don't say this

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

Most common mistake

Trying to absorb extreme write workloads into a live HNSW or IVF index. The index degrades faster than maintenance can repair it, recall drops silently, and the operational story unravels.

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.