When a language model answers from your own data, it isn't reading your database. It's reading a vector index built from it, and that index is only as current as its last build. Refresh it nightly, and the model answers confidently from yesterday's prices, inventory, or account status, and every refresh re-embeds everything to catch the one percent that changed.

Change data capture closes that gap. We'll walk through a working pipeline, all in Java: PostgreSQL, Debezium Server computing embeddings in flight and writing them straight into Milvus with no Kafka in between, and a Quarkus service using LangChain4j answering questions over data that changed seconds earlier. Along the way:

- Deletes and updates in a vector index, and why tombstones matter.
- Chunking rows that don't look like documents.
- Where embedding should run: pipeline, sink, or application.
- Rebuilding the index without stopping the stream.
- Measuring lag from commit to vector store, and catching stale answers before users do.
- Offsets, restarts, and what happens when the vector store is down.

No CDC background needed. You'll leave with a design to keep retrieval in step with the system of record, plus a checklist to run it.

Target audience: developers who have shipped or are about to ship a retrieval or RAG feature against a live database, and the platform and data engineers who have to keep it accurate afterward. Intermediate. Basic familiarity with embeddings and vector search is assumed. No change data capture experience is needed; I cover it from scratch early in the talk.

Format and duration: regular 55-minute session, about 45 minutes of talk and demo with 10 minutes for questions.

Demo and technical requirements: the demo is a pre-built pipeline running on my laptop in containers: PostgreSQL, Debezium Server with the embeddings transformation writing directly to Milvus (no Kafka), and a Quarkus service using LangChain4j. Embeddings and the answering model run locally, so the demo does not depend on conference Wi-Fi or a hosted API. I need a projector with HDMI and a power outlet. The demo shows a finished pipeline with one change made live so the audience sees the freshness difference; there is no on-stage building.

First public delivery: yes. This is a new talk written for Devnexus 2027.

Related prior talks: none on this topic. My previous Devnexus session (2023) was on change data streaming patterns in distributed systems and did not cover AI or vector workloads.

Additional information: everything shown is open source and vendor-neutral. Debezium is a Commonhaus Foundation project. I started Debezium's JDBC sink connector and am building its Elasticsearch sink, so the sink-side problems in this talk (upserts, deletes, and tombstones landing in a target that was not designed for a change stream) are ones I have solved in code rather than observed. The pipeline deliberately runs without Kafka to show that CDC into a vector store is a single-process concern; the same connector runs under Kafka Connect for teams that already have it. The talk fits Production AI Engineering because it is about what happens after the RAG prototype works, and it speaks to the track's call for systems that are observable and economically sustainable: the pipeline re-embeds only what changed rather than the whole corpus, and exposes end-to-end lag as a metric you can alert on; it would also fit Building AI-Native Applications if the committee prefers.