If you’ve followed this RAG series from Naive RAG<\/a> through Hybrid Search<\/a>, Adaptive RAG<\/a>, and Agentic RAG<\/a>, you’ve seen how retrieval quality is the backbone of any RAG system. But here’s what I didn’t cover explicitly: what happens when your retrieval quality silently degrades because your embeddings are stale?<\/strong><\/p>\n\n\n\n This is the silent killer of RAG in production. Nobody complains about the embedding pipeline, they complain that the chatbot gives wrong answers. And by the time you trace it back to stale embeddings, the trust is already gone.<\/p>\n\n\n\n In this post, I want to bridge two worlds that I’ve been working in simultaneously: the CDC\/event-driven pipelines<\/strong> I demonstrated in my PostgreSQL CDC to JDBC Sink<\/a> and Oracle to PostgreSQL Migration with Flink CDC<\/a> posts, and the RAG\/pgvector<\/strong> world from this series.<\/p>\n\n\n\n The thesis is straightforward: if you’re serious about production RAG, you need event-driven embedding refresh. Batch re-embedding is technical debt waiting to happen.<\/strong> Event-driven architecture and data pipelines are a precondition to hosting similarity search. Organizations that are still 100% batch-processed are all migrating towards event-driven because of a probable need for live KPIs instead of daily refreshes. This is facilitated by the current maturity of the solutions that are out there. The “hidden” bonus of streaming data from your data sources to a data lake and to your data marts is that it facilitates refreshes of embeddings as well.<\/p>\n\n\n\n This is Part 1 covering the architecture and design patterns I feel are relevant. In Part 2<\/a>, I walk through a hands-on LAB on 25,000 Wikipedia articles with real output, actual numbers, and some of the edge cases you would encounter applying this in practice.<\/p>\n\n\n\n Let me paint a picture that I’ve seen in real consulting engagements.<\/p>\n\n\n\n A company builds a RAG system for internal documentation. Knowledge base: 50,000 documents in PostgreSQL. Embeddings generated with Three months later:<\/p>\n\n\n\n The result: your vector index is lying to you<\/strong>. Similarity search returns chunks from outdated documents. The LLM generates answers based on stale context. Users lose trust.<\/p>\n\n\n\n This is not a hypothetical. This is the reality of most RAG deployments I’ve encountered.<\/p>\n\n\n\n The naive approach is: “just re-embed everything periodically.” Let’s do the math.<\/p>\n\n\n\n For 50,000 documents, assuming an average of 10 chunks per document:<\/p>\n\n\n\n Now multiply this by:<\/p>\n\n\n\n The cost isn’t the API calls. The cost is the operational complexity<\/strong>: coordinating the backfill, monitoring progress, handling rate limit errors, and \u2014 critically \u2014 the lack of observability<\/strong> into which documents actually changed. Batch treats every document the same, whether it was modified yesterday or hasn’t been touched in six months.<\/p>\n\n\n\n But there’s a problem that comes before stale embeddings, and in my consulting experience, it’s far more common: most organizations don’t measure retrieval quality at all.<\/strong> They deploy a RAG system, it works in demo, it goes to production, and then nobody instruments it. There is no precision@k, no nDCG, no confidence scoring. The embedding pipeline might be stale, or it might be fine \u2014 they literally cannot tell.<\/p>\n\n\n\n In the Adaptive RAG<\/a> post, I introduced the metrics framework that makes retrieval quality measurable: precision@k<\/strong> (are the retrieved documents relevant?), recall@k<\/strong> (are we finding all the relevant documents?), nDCG@k<\/strong> (are the best results ranked first?), and confidence scores<\/strong> (how certain is the system about its top result?). In the Agentic RAG<\/a> post, I added decision metrics on top of that \u2014 tracking whether the agent made the right call about when to retrieve. The evaluation framework in the pgvector_RAG_search_lab repository<\/a> ( These metrics were originally designed to compare search strategies and tune parameters. But here’s the connection to embedding freshness that I want to make explicit: the same metrics that tell you whether your search is working also tell you whether your embeddings are drifting.<\/strong> If your weekly nDCG is declining, if your confidence distribution is shifting toward lower values, if precision@10 is dropping for a subset of queries \u2014 those are the leading indicators that your embeddings are falling behind your content. Not the queue depth, not the pipeline latency. The quality metrics.<\/p>\n\n\n\n I have seen architectures where teams built elaborate embedding pipelines \u2014 cron jobs, Airflow DAGs, custom orchestrators \u2014 but never implemented the measurement layer. The pipeline runs on schedule, embeddings get refreshed, and everyone assumes it’s working. But without retrieval quality metrics, you have no way to know if you are going in the right direction. You might be re-embedding documents that don’t need it (wasting API spend) and missing documents that do (degrading search quality). Worse, I have seen setups where the metrics exist but are so poorly instrumented \u2014 wrong ground truth sets, no temporal dimension, no per-topic breakdown \u2014 that the numbers are misleading. An aggregate nDCG of 0.82 can hide the fact that an entire topic cluster has dropped to 0.45.<\/p>\n\n\n\n Building the pipeline is one thing. Proving you’re going in the right direction is everything.<\/p>\n\n\n\n This is why this post covers both. The first two-thirds address the pipeline: how to detect changes, how to queue and process them, how to decide what’s worth re-embedding. But the final section \u2014 Monitoring Embedding Freshness<\/a> \u2014 is where it all comes together. That’s where the retrieval quality metrics from the Adaptive RAG post become operational canaries<\/strong> for embedding drift. The pipeline reacts to content changes; the monitoring layer tells you whether the pipeline is actually keeping your RAG system healthy. You need both.<\/p>\n\n\n\n The answer is the same pattern I demonstrated in the CDC posts: react to changes as they happen.<\/strong><\/p>\n\n\n\n Instead of asking “when should I re-embed?”, the question becomes: “a row changed \u2014 which embeddings need updating?”<\/strong><\/p>\n\n\n\n Here’s the architecture I’m proposing:<\/p>\n\n\n\n There are three levels of sophistication here, and I want to walk through each one because not every project needs the most complex solution<\/strong>.<\/p>\n\n\n\n If your source data and embeddings live in the same PostgreSQL instance (which they probably do if you’ve been following this series), you don’t need Flink. You don’t need Kafka. You need a trigger.<\/p>\n\n\n\n First, let’s design a proper embedding table that supports versioning. This is the piece most tutorials skip:<\/p>\n\n\n A few things to notice here:<\/p>\n\n\n\n Rather than embedding synchronously in a trigger (which would block the transaction and hit external APIs), we use a queue pattern<\/strong>:<\/p>\n\n\n Note the The key insight here<\/strong> is the An alternative approach that’s even more targeted: use
\n\n\n\nThe Problem: Stale Embeddings<\/h2>\n\n\n\n
text-embedding-3-small<\/code>, stored in pgvector. Everything works great on day one.<\/p>\n\n\n\n\n
Why batch re-embedding doesn’t scale<\/h3>\n\n\n\n
\n
text-embedding-3-small<\/code>: ~$5 per full re-embed<\/strong> (not terrible)<\/li>\n\n\n\n\n
The deeper problem: you can’t fix what you don’t measure<\/h3>\n\n\n\n
lab\/evaluation\/metrics.py<\/code>, compare_search_configs.py<\/code>, k_balance_experiment.py<\/code>) implements all of this concretely.<\/p>\n\n\n\n
\n\n\n\nThe Solution: Event-Driven Embedding Refresh<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2026\/02\/image-9-1024x680.png\")
<\/figure>\n\n\n\n
\n\n\n\nLevel 1: PostgreSQL Triggers \u2014 The Simplest Path<\/h2>\n\n\n\n
Schema design with versioning<\/h3>\n\n\n\n
\n-- Source table (your knowledge base)\nCREATE TABLE documents (\n doc_id BIGSERIAL PRIMARY KEY,\n title TEXT NOT NULL,\n content TEXT NOT NULL,\n category TEXT,\n content_hash TEXT GENERATED ALWAYS AS (md5(content)) STORED,\n updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),\n is_active BOOLEAN NOT NULL DEFAULT true\n);\n\n-- Embedding table with versioning support\nCREATE TABLE document_embeddings (\n embedding_id BIGSERIAL PRIMARY KEY,\n doc_id BIGINT NOT NULL REFERENCES documents(doc_id) ON DELETE CASCADE,\n chunk_index INT NOT NULL,\n chunk_text TEXT NOT NULL,\n embedding vector(1536), -- text-embedding-3-small\n model_name TEXT NOT NULL DEFAULT 'text-embedding-3-small',\n model_version TEXT NOT NULL DEFAULT 'v1',\n source_hash TEXT NOT NULL, -- md5 of the source content at embed time\n embedded_at TIMESTAMPTZ NOT NULL DEFAULT now(),\n is_current BOOLEAN NOT NULL DEFAULT true,\n \n UNIQUE(doc_id, chunk_index, model_name, model_version)\n);\n\n-- Index for similarity search (only current embeddings)\n-- Using pgvectorscale's StreamingDiskANN for better performance at scale\nCREATE INDEX idx_embeddings_diskann ON document_embeddings \n USING diskann (embedding vector_cosine_ops)\n WHERE is_current = true;\n\n-- Index for version lookups\nCREATE INDEX idx_embeddings_version ON document_embeddings (doc_id, model_version, is_current);\n\n-- Index for staleness detection\nCREATE INDEX idx_embeddings_staleness ON document_embeddings (source_hash, is_current)\n WHERE is_current = true;\n\n-- Safety: prevent two "current" chunk sets for the same doc + model space\nCREATE UNIQUE INDEX uq_doc_current_per_space\n ON document_embeddings (doc_id, model_name, model_version, chunk_index)\n WHERE is_current;\n\n<\/pre><\/div>\n\n\n
\n
content_hash<\/code><\/strong>: a generated column that gives us a fast way to detect if content actually changed (not just updated_at<\/code>). If you’re adding this to an existing table with data, note that ALTER TABLE ... ADD COLUMN ... GENERATED ALWAYS AS ... STORED<\/code> requires touching\/recomputing all rows \u2014 plan a maintenance window, or use a BEFORE UPDATE<\/code> trigger with NEW.content_hash := md5(NEW.content)<\/code> instead. Both approaches are functionally equivalent.<\/li>\n\n\n\nsource_hash<\/code><\/strong> on the embedding: captures what the source content looked like when the embedding was generated<\/li>\n\n\n\nis_current<\/code><\/strong>: soft versioning \u2014 old embeddings are kept for rollback. The partial unique index uq_doc_current_per_space<\/code> guarantees at the database level that you can never have two “current” chunk sets for the same document within the same model space \u2014 even if your application has a bug.<\/li>\n\n\n\nCREATE INDEX ... WHERE ...<\/code>) are standard PostgreSQL \u2014 validated in our lab with pgvectorscale’s StreamingDiskANN (see Part 2 \u2014 Lab Walkthrough<\/a>). If your pgvectorscale version doesn’t support partial predicates, pgvector’s HNSW partial index is an equivalent fallback.<\/li>\n\n\n\nmodel_version<\/code><\/strong>: critical for model upgrades (more on this later)<\/li>\n<\/ul>\n\n\n\nThe embedding queue pattern<\/h3>\n\n\n\n
\n-- Queue table for pending embedding work\nCREATE TABLE embedding_queue (\n queue_id BIGSERIAL PRIMARY KEY,\n doc_id BIGINT NOT NULL REFERENCES documents(doc_id),\n change_type TEXT NOT NULL DEFAULT 'content_update',\n content_hash TEXT,\n queued_at TIMESTAMPTZ NOT NULL DEFAULT now(),\n claimed_at TIMESTAMPTZ, -- set when a worker claims the item\n processed_at TIMESTAMPTZ,\n status TEXT NOT NULL DEFAULT 'pending' \n CHECK (status IN ('pending', 'processing', 'completed', 'failed', 'skipped')),\n error_message TEXT,\n retry_count INT NOT NULL DEFAULT 0\n);\n\nCREATE INDEX idx_queue_pending ON embedding_queue (status, queued_at) \n WHERE status = 'pending';\n\n<\/pre><\/div>\n\n\nskipped<\/code><\/strong> status \u2014 this is used by the change significance detector (covered later) when it determines that a content change is too minor to warrant re-embedding. The item stays in the queue for audit purposes, but no embedding API call is made.<\/p>\n\n\n\nThe trigger<\/h3>\n\n\n
\nCREATE OR REPLACE FUNCTION fn_queue_embedding_update()\nRETURNS TRIGGER AS $$\nBEGIN\n IF TG_OP = 'INSERT' THEN\n INSERT INTO embedding_queue (doc_id, change_type, content_hash)\n VALUES (NEW.doc_id, 'content_update', NEW.content_hash);\n RETURN NEW;\n \n ELSIF TG_OP = 'UPDATE' THEN\n -- Only queue if content actually changed (not just metadata)\n IF OLD.content_hash IS DISTINCT FROM NEW.content_hash THEN\n INSERT INTO embedding_queue (doc_id, change_type, content_hash)\n VALUES (NEW.doc_id, 'content_update', NEW.content_hash);\n END IF;\n RETURN NEW;\n \n ELSIF TG_OP = 'DELETE' THEN\n INSERT INTO embedding_queue (doc_id, change_type, content_hash)\n VALUES (OLD.doc_id, 'delete', OLD.content_hash);\n RETURN OLD;\n END IF;\nEND;\n$$ LANGUAGE plpgsql;\n\nCREATE TRIGGER trg_embedding_queue\n AFTER INSERT OR UPDATE OR DELETE ON documents\n FOR EACH ROW\n EXECUTE FUNCTION fn_queue_embedding_update();\n\n<\/pre><\/div>\n\n\n
content_hash<\/code> comparison on UPDATE. If someone updates the category<\/code> or title<\/code> but the actual content hasn’t changed, we don’t waste an API call re-embedding identical text. This is a simple optimization but it saves real money at scale. In my lab tests on 25K Wikipedia articles, 12% of simulated mutations were metadata-only \u2014 the trigger correctly skipped all of them.<\/p>\n\n\n\nAFTER INSERT OR UPDATE OF content<\/code> to only fire the trigger when the content column is modified. This is what I did in the LAB (see Part 2<\/a>) because the articles<\/code> table didn’t have a content_hash<\/code> column originally. Both approaches achieve the same goal.<\/p>\n\n\n\n\n
![\"\"](\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2026\/02\/image-10-1024x383.png\")
<\/figure>\n\n\n\n