Change Data Capture Explained: Real-Time Data Without Killing Your ERP

When teams first connect dashboards or AI agents to a legacy ERP, they almost always start the same way: a cron job that queries JobHead, inventory, or purchase orders every 30–60 seconds.

It works in a demo. In production it competes with planners, finance, and shop-floor terminals for database capacity. You still miss events between polls. And you teach every new integration the same bad habit.

Change Data Capture (CDC) is the architecture that fixes this: read the database's own change stream (transaction log / WAL), not the tables, and push events downstream the moment they commit.

CDC watches inserts, updates, and deletes as they are written by the ERP. Instead of asking "give me all open jobs again," your middleware receives "Job 4521 status changed to Complete at 14:03:12."

• Low impact on OLTP — log readers are designed for this workload
• Near real-time latency — often sub-second to a few seconds
• Complete history of changes — including who/what if your ERP records it
• Fan-out friendly — one stream can feed AI agents, warehouses, and dashboards

ERP SQL Server / Postgres
        → CDC connector (e.g. Debezium)
        → Event bus (Kafka / similar)
        → Middleware (filter, enrich, auth)
        → AI agents · dashboards · webhooks

On Epicor Kinetic we typically enable CDC on JobHead, JobOper, and JobMtl first — the tables that drive scheduling agents. Inventory and purchase-order tables follow once the pipeline is proven.

You will still use ERP REST/OData APIs for intentional writes and for BAQs that join context. CDC is for knowing that something changed — then you fetch rich context once, not forever.

• CDC not enabled on the right tables (or not enabled at all)
• Connector credentials that lack log-reader permissions
• Ignoring schema evolution when the ERP patch adds columns
• Streaming every column to the LLM — flood the agent; filter and enrich first
• No dead-letter handling — one poison event stalls the consumer

CDC does not mean opening the SQL port to the public internet. Keep the connector inside your network or VPN, publish only sanitised events through your middleware, and enforce OAuth/JWT for anything an AI agent or cloud service calls.

Rate-limit downstream consumers separately from the CDC pipeline so a misbehaving agent cannot amplify load back onto the ERP.

Scheduling, maintenance, and quality agents need events, not yesterday's spreadsheet. When a machine completes an operation, CDC can notify the agent in seconds so recommendations stay grounded in the live factory — not last night's export.

Without CDC (or an equivalent event source), you are stuck with polling theatre or batch AI that arrives too late to change the shift.

1. Pick one high-value table group (jobs/operations)
2. Enable CDC in a maintenance window with DBA support
3. Stand up a connector → bus → middleware path in non-prod first
4. Prove latency and correctness against known job transitions
5. Only then wire an AI agent or live dashboard

If you want a readiness check on your ERP database and a scoped CDC pilot, book a free assessment — we will tell you whether log-based CDC is available on your stack and what the smallest useful stream looks like.