The demo that sells a team on change data capture ends at the wrong place. A row changes in the source, an event appears on a topic, and everyone nods. Real-time. Done. Except a stream of change events on a topic is raw material, not a working integration. Between that event and a correctly updated downstream system sits every hard part of the job, and none of it was in the demo.
That gap is where CDC and iPaaS meet. The capture engine gives you a change stream; an integration platform is what turns the stream into a pipeline you can run in production. Worth being precise about what “the rest” actually is, because it’s most of the work and it’s the part that decides whether this holds up under load.
What the stream doesn’t give you
A change event says “row 4471 in orders went from state A to state B.” That’s it. Everything that has to happen next is yours to build.
- Routing and filtering. Not every consumer wants every change. One system cares about status transitions, another only about new rows, a third about a single column. Raw, that’s every consumer subscribing to everything and discarding most of it. A pipeline routes by content so each destination gets only what it needs.
- Transformation. The source schema is the source’s, shaped for its own writes. The destination expects its own shape. Somewhere between them a change has to be reshaped, enriched, sometimes joined against a second source, and the change stream does none of that for you.
- Idempotent load. The stream is at-least-once, so the same change will eventually arrive twice. The write at the far end has to absorb a duplicate without creating one, which means an upsert keyed on a stable change id, not a naive insert. This is yours to get right on every destination.
- Reconciliation. Streams drift. An event is missed, a consumer is down for an hour, a replay double-applies. Real pipelines pair the live stream with a periodic batch that re-checks the two sides and heals the gaps. The change stream has no opinion about its own completeness.
None of this is exotic. It’s the standard content of a production integration. The point is that CDC delivers exactly none of it, and a team that stops at “the events are flowing” has built the first tenth of the system and shipped it.
A change stream is the easy tenth of a CDC integration. The other nine tenths are an integration platform, whether you buy one or accidentally build one.
The build-it-yourself tax
You can, of course, write all of that by hand. Most teams do at first, because at the start it’s just one pipeline and the routing is a switch statement. Then it’s five pipelines, each with its own bespoke idempotency logic, its own reconciliation job someone wrote on a deadline, its own retry handling that works differently from the other four. The change stream was the easy part. What you actually built is a small, undocumented integration platform, and now you operate it.
The operational side arrives right behind it. Every one of those hand-rolled pipelines needs to answer the same questions when it breaks: which change caused this, did it run, why did it fail, can we replay it. If the answer lives in application logs scattered across services, every incident is an archaeology dig. On-premises and self-managed integration estates accumulate this cost quietly. The engineers who wrote each pipeline move on. The reconciliation job that only runs at 3 a.m. is understood by no one. The behavior drifts from the documentation, because the documentation was a design doc and the pipeline is what actually runs.
This is the real argument for putting an integration platform between the change stream and its destinations. Not because hand-rolling is impossible, but because the ninth-tenth you’re building is a solved problem, and solving it once per team is a tax you keep paying.
The choice isn’t “iPaaS or no iPaaS.” It’s “an integration platform you chose, or one you assembled by accident.”
What the platform is supposed to add
An integration platform earns its place here by making the hard nine-tenths into properties you configure instead of code you maintain. Routing by content, transformation with a real mapping engine, idempotent receivers keyed on a change id, dead-letter handling with replay, and a scheduled reconciliation pass that heals drift. The change stream plugs in as one activity; the pipeline is composed around it.
The part that’s easy to undervalue until an incident is observability. A change flowing through the pipeline should be a trace you can follow end to end: which event, which route, which transform, which write, and where it stopped if it stopped. When that telemetry is in a standard, queryable format, it lands in the observability stack the team already runs, rather than in a proprietary log viewer someone checks only when something’s already wrong. The difference between a five-minute investigation and a lost afternoon is almost never the capture method. It’s whether the pipeline around it was built to be seen into.
Governance is the other quiet requirement. A CDC pipeline is production-critical plumbing wired directly into a source database, which makes “what changed in this pipeline’s config, when, and who approved it” a real question. When the pipeline is a version-controlled file in a real repository rather than clicked-together state inside a console, that question has an answer: a diff, a branch, a reviewed change. The schema change that silently poisoned a stream becomes a reviewed change instead of a surprise.
Where an iPaaS is the wrong tool
Be honest about the boundary. If your workload is extreme-throughput log-based replication with sub-second latency budgets and exactly-once enforced at the pipeline level, a general integration platform isn’t what you want between the source and the sink. That’s a case for a purpose-built streaming engine and a broker you tune and staff. Same if CDC is your actual product, or if the job is a one-time bulk migration rather than a standing integration. The platform argument is for the common case: a handful of systems that need to stay in sync, real but not extreme volume, and a team that would rather compose the pipeline than operate a streaming stack to run it.
Even then, the two aren’t exclusive. Point a purpose-built engine at the source for the raw capture, and consume its stream through the platform for everything downstream. Owning the capture and owning the pipeline are separate decisions, and the second one is where most of the ongoing cost actually lives.
The shape of it
Change data capture and an integration platform are complementary, not competing. CDC answers “how do I know something changed.” The platform answers “how does that change arrive correctly, once, transformed, routed, reconciled, and visible.” Treating the change stream as the finished product is the mistake, because the stream is the input to the real work, not the output.
So when you’re weighing how to run CDC, the decision that matters isn’t the capture method. It’s whether the nine-tenths that come after the capture — routing, transformation, idempotent load, reconciliation, and the observability to see it all — will be a platform you chose and configure once, or one you assemble by accident, one hand-rolled pipeline at a time, and end up operating anyway. The capture is the easy part. The pipeline is the decision.