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.

Attempt it

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

Sign in for the mnemonic that makes this stick. See Pro pricing.

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

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?

Sign in or go Pro to see the approach for this follow-up.

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

Sign in or go Pro to see the approach for this follow-up.

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

Sign in or go Pro to see the approach for this follow-up.

60-second cheat sheet

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

Sign in for 5 unlocks/day or go Pro for unlimited revision sheets. See Pro pricing.

References

Primary sources. Skim if you want the original framing.