You upsert a document and query for it 200 milliseconds later, but it never appears. Pick the most likely cause.

MCQ·Easy·4.0 · 0·~1 min

Attempt it

Vector databases separate two things: storing a write durably (the upsert returns success) and making the vector findable by a query (the index has to update). The gap between the two is called the freshness window. **Why it exists.** Indexes like HNSW and IVF are not designed for one at-a time updates. Inserting a single vector into a built HNSW graph means walking the graph and stitching the new node in, which is expensive. Production engines batch writes: incoming vectors go into a memtable, a write ahead log, or a small fresh segment. Every so often (milliseconds to minutes, depending on the engine and tier), the engine flushes the buffer or merges the fresh segment into the main index. Only after that step is the vector searchable. **Why 200 ms is well inside that window.** Pinecone serverless typically takes seconds, Elasticsearch defaults to a 1-second refresh interval, Milvus has explicit consistency levels with documented staleness. A 200 ms query right after an upsert almost always lands in the gap. The other options do not match the symptom. Vectors are not silently rejected for normalization; approximation lowers recall a little but does not permanently hide new entries; and the embedding model has nothing to do with index visibility.

**Freshness lag** is the right answer because every production vector database documents some version of this behaviour. The write path looks like: client sends upsert, engine writes to a write ahead log for durability, engine adds the vector to an in memory buffer or a fresh segment, engine acknowledges success to the client. None of those steps update the searchable index. A background task flushes the buffer or merges the segment on its own schedule, and the vector becomes queryable only after that. The window is engine specific: - **Pinecone serverless.** A few seconds at the freshness layer, longer to fully merge into the main index. - **Elasticsearch / OpenSearch.** Default refresh interval is 1 second; can be lowered at a CPU cost or set to immediate per request. - **Milvus.** Explicit consistency levels (strong, bounded, session, eventual); eventual is the cheap default. - **Qdrant.** Writes are visible after the WAL flush, typically sub-second but configurable. - **pgvector.** Writes are immediately visible in the table but only show up in the IVFFlat or HNSW index after the index sees them, depending on engine version and settings. The trap for application developers is assuming write after read consistency. Vector databases default to eventual consistency on the read path for performance reasons. The fix is to either query the strong consistency path (where supported), to wait a documented refresh interval, or to design the application so freshness lag is acceptable (a chat that displays the just written doc from the application database, not the index).

Quick reference

TL;DR

Write acknowledgement and search visibility are separate steps; the upsert is durable but waits in a buffer or fresh segment until the next flush or refresh makes it queryable.

Memory aid

Easy to grasp

Imagine handing a note to a librarian who immediately puts it in a tray on the counter and says, got it. The note is safe and is going into the catalogue, but the catalogue card has not been typed and filed yet. If you ask the catalogue ten seconds later whether the note exists, the catalogue says no, because the typing happens in batches every few minutes. The note is not lost. The catalogue simply has a refresh schedule, and your query landed between two refreshes. Most vector databases work the same way: a write is accepted and durable long before it is searchable.

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.

4 minutes: state durability versus queryability, name the freshness window for two or three engines, and describe the read your own writes pattern.

Real-world examples

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

Pinecone serverless documents a freshness layer with second scale staleness for the most recent writes before they merge into the main index
Elasticsearch and OpenSearch ship with a one second default refresh interval; per request refresh exists for tests but is the wrong default for production
Milvus exposes four consistency levels (strong, bounded, session, eventual) so the application can pick its own staleness budget per query
Qdrant write acknowledgement happens at WAL flush, and the standard pattern for read your own writes is to query the application database for the just written document

Interviewer follow-ups

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

QHow would you give the application read your own writes without forcing strong consistency on every query?

QWhat is the cost of setting refresh_interval to immediate in Elasticsearch?

Don't say this

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

Most common mistake

Assuming write acknowledgement equals search visibility, then chasing phantom bugs in upsert payloads when the real cause is a documented freshness window.

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.