What Are Stale Embeddings?

What are stale embeddings?

An embedding is derived data: a function of the source content, the model and the preprocessing that turned the content into model input. When the model or preprocessing changes, or the incoming data shifts, that is embedding drift. When only the content changes, the stored vector is stale until something recomputes it.

Recomputing takes time because generating an embedding is a model call, usually to an external service. Supabase's automatic embeddings guide puts it plainly: unlike full-text search, which Postgres can update synchronously with triggers, "semantic search requires asynchronous API calls to a provider like OpenAI to generate vector embeddings." Its design uses triggers to enqueue jobs and Edge Functions to generate the new vectors, and it states the consequence: "an embedding can be temporarily out of sync with the content until the new embedding is generated and updated." The guide offers an optional trigger that clears the old embedding on update, for applications where an accurate embedding matters more than having one.

How embeddings go stale

Three paths:

1. 1.Missed updates. The source changes and nothing enqueues a re-embed, because the job looks only for new rows or an edit bypassed the code path that enqueues work.
2. 2.Queue lag. The re-embed is enqueued but not yet processed. Under a burst of edits, or when the embedding provider throttles, the queue grows and so does the stale window.
3. 3.Missed deletes. The source row is gone but its vector remains in a separate index, so search keeps returning it.

Chunking adds a wrinkle. A document split into chunks has many vectors, and an edit to one paragraph makes some of them stale while the rest stay valid.

Staleness is cheap to detect if each row records which version of its content was embedded:

ALTER TABLE documents
  ADD COLUMN content_version  bigint NOT NULL DEFAULT 1,  -- bumped on every edit
  ADD COLUMN embedded_version bigint;                     -- set by the embedding worker

-- Work queue: rows whose vector predates their current content
SELECT id FROM documents
WHERE  embedded_version IS DISTINCT FROM content_version;

-- Query-time guard: rank only vectors that match the current content
SELECT id, title
FROM   documents
WHERE  embedded_version = content_version
ORDER  BY embedding <=> $1
LIMIT  10;

The guard trades recall for correctness: an item mid-re-embed drops out of results instead of ranking on old text. With an approximate index, that WHERE clause is a filter on the vector search, with the recall behavior described under filtered vector search.

Why stale embeddings matter in real-time systems

An embedding is one kind of derived context, and like any derived value it trails its source by the time the pipeline takes to recompute it. For a knowledge base that changes a few times a day, a trigger and a queue with pgvector are enough, and the stale window rarely matters. It matters when the content behind the vectors changes during the interaction that reads it: a support ticket updated mid-conversation, an agent's memory of a task it just changed, a listing edited minutes before a buyer's search.

Re-embedding is a model call wherever it runs, so the vector trails its source by the worker's lag. What Tacnode changes is everything around the vector. The embedding, the source row's other fields, its version columns and any joined state live in one system, so ranking by similarity, filtering on the row's other fields and excluding stale vectors all read one snapshot. For a broader view of how lagging derived data affects decisions, see what is stale data.

FAQ