When a language model answers questions from your own data using a pattern known as Retrieval-Augmented Generation (RAG), it is not reading your database. It is reading a vector index of embeddings built from the database, and that index is only as current as its last build. The data behind it lives in a relational or NoSQL datastore like PostgreSQL, Oracle, or MongoDB and changes all day, while the index refreshes at set intervals. This can lead your model to answer confidently based on stale prices, inventory, account status, or other mission-critical information. In addition, batch re-embedding scales badly: it recomputes everything to catch the small percentage of actual changes.

Change data capture (CDC) closes this gap. Debezium, an open-source CDC platform, reads database transaction logs and emits an event for every change in near real time. Recent releases add the pieces to build reliable retrieval pipelines: vector column support in PostgreSQL, MySQL, and Oracle 26ai, along with an embeddings transformation that uses a local or hosted model. Paired with Debezium Server, those changes and embeddings can be written directly to Milvus or Qdrant, with no Kafka infrastructure in between.

We'll walk through a working pipeline, all in Java: an application writing an ordinary row to PostgreSQL, Debezium Server computing embeddings in-flight and storing them in Milvus, and a Quarkus service using LangChain4j answering questions about data that changed only seconds earlier. Along the way, you'll learn about:

- Deletes and updates in a vector index, and why tombstones are vital
- Chunking and field selection for rows that don't look like documents
- Where embedding should run: in the pipeline, in the sink, or in the application
- Rebuilding the index from a fresh snapshot without stopping the stream
- Running it: where offsets live, what a restart replays, and what happens when the vector store is unavailable

No CDC background is needed. You'll leave with a design for keeping RAG in step with the system of record, and the operational checklist to run it.