Change data capture has become the default recommendation for any pipeline that needs to feel modern. It is a powerful pattern. It is also, in a meaningful share of cases, the wrong one. The decision between CDC and batch ingestion is not a maturity question; it is a fit question, and the cost of getting it wrong is paid in operational complexity that does not translate into business value.
What CDC actually requires
CDC reads change events from a source database — typically the transaction log — and propagates them to a downstream system in near real time. To do this reliably, you need: log retention configured on the source long enough to survive a downstream outage; a connector that handles schema evolution without losing events; an ordering and exactly-once story that holds up under partition rebalances; backpressure handling when the downstream is slower than the source; and a runbook for the day someone truncates a table or runs a bulk update and produces a hundred million events in twenty minutes.
None of these are unreasonable. All of them are real engineering. A team that adopts CDC is committing to operating a streaming substrate, not just a pipeline.
When CDC is the right answer
CDC earns its complexity when latency is a product requirement, not a stakeholder preference. A fraud-scoring model that needs transactions within seconds. An inventory system where stale data causes oversells. A personalization layer where the freshness of behavioral data is the feature. A compliance use case where the auditable record requires every change, not just the latest state.
CDC is also right when batch windows are no longer feasible — when the source is large enough or hot enough that a nightly full extract impacts production, and incremental extraction by timestamp is unreliable because of soft deletes, late-arriving updates, or columns that do not move when rows do.
When CDC is overkill
For most analytics workloads, the latency requirement is “this morning’s data by the time the team logs in.” That is a batch problem. A well-built batch pipeline running every fifteen minutes — or even hourly — will satisfy nearly every dashboard, every weekly business review, every quarterly board metric, and most operational reports. The marginal value of moving from fifteen-minute to fifteen-second latency is, for these use cases, zero. The marginal cost is significant.
CDC is also overkill when the source system cannot support it well. A legacy ERP without proper log access, a SaaS application whose webhooks drop events under load, a database whose DBA team has not signed up for the operational implications — these are sources where CDC will technically work and operationally drift. Batch extraction with a clear watermark and a periodic reconciliation is more honest about what the source can support.
And CDC is overkill when the team operating it does not have the depth to run a streaming system. Streaming pipelines fail differently than batch ones. They fail silently, partially, with backlog. The on-call engineer who can debug a batch job that did not run cannot necessarily debug a Kafka consumer group whose lag is climbing for reasons that are not yet clear. If the team does not have that depth, CDC is a future incident, not a current capability.
A useful decision frame
Three questions, in order. First, what is the latency requirement, stated as the longest acceptable delay between a source event and a downstream decision? If the answer is measured in hours, batch is sufficient. Second, can the source support log-based extraction without operational risk to the transactional system? If not, batch with a robust watermark is the more durable choice. Third, does the team have the streaming operational maturity to run CDC at the relevant scale, including failure modes? If not, the right path is to build that capability deliberately on a less critical pipeline before betting a core flow on it.
The hybrid case
Most mature platforms run both. CDC for the handful of pipelines where latency is a product requirement; batch for everything else. The mistake is to treat CDC as the destination state and batch as the legacy state. They are different tools. Choosing the right one for each pipeline is the discipline.
What this means for the platform decision
When evaluating ingestion vendors and architectures, the question is not whether CDC is supported. The question is whether the architecture allows you to mix CDC and batch cleanly, to switch a pipeline from one to the other without rebuilding it, and to operate both with the team you actually have. That is a different evaluation than the demo will suggest, and it produces a different shortlist.