Does Your CDC Pipeline Know When a Column Changes Meaning?

Change data capture pipelines have gotten very good at surviving change. Debezium reads the write-ahead log or binlog and turns row-level inserts, updates, and deletes into a stream of events. Fivetran and Airbyte poll source connectors, watch for new tables and columns, and adjust the destination schema to match. When a source table changes shape, most modern CDC tooling notices and keeps streaming instead of falling over.

That is a real engineering achievement, and it solves a real problem. It is also a different problem from the one that actually costs data teams the most time: knowing when a field still exists, still has the right type, and still means something different than it did last month.

What CDC actually catches

Change data capture exists to move only what changed, in near real time, without re-scanning an entire table on every run. Debezium does this by tailing the database transaction log at the storage layer, so it sees every committed row change as it happens. Fivetran and Airbyte work closer to the connector layer, periodically checking source schemas and reconciling any differences against the destination.

This is DDL awareness. When someone runs an ALTER TABLE statement to add a loyalty_tier column, a well-built CDC pipeline notices the new column and starts replicating it without manual intervention. When a column widens from int to bigint, the pipeline adjusts the destination type instead of throwing an error and halting the sync. Most of the pipeline breakage that used to page data engineers at 3 a.m. has been designed away by exactly this kind of automatic schema evolution.

Where structural change and semantic change diverge

None of that tells you whether the values flowing through the pipe still mean what they used to.

Say a product team decides that an order_status value of cancelled should now also cover orders that were killed by a fraud check, a case that used to get its own status, fraud_hold. No column was added. No type changed. The DDL is untouched, so a CDC pipeline sees nothing worth flagging. But every downstream system that joins on order_status, every dashboard that counts cancelled orders, every automated refund job triggered off that value, is now running against a definition that shifted underneath it without anyone signing off.

Or say a source system starts writing timestamps in UTC instead of the account's local timezone, after a configuration change nobody thought to document. The column is still a timestamp. Its type has not changed. The pipeline replicates it faithfully, row by row, exactly as instructed. The data is now off by whatever the timezone offset happens to be, and it stays that way until a report doesn't add up and someone starts digging.

These are not edge cases. They are the normal way schema drift happens once a team has already solved the structural problem: the failure moves from the shape of the data to the meaning of it, precisely because nobody is watching that layer anymore.

Where Debezium, Fivetran, and Airbyte stop, on purpose

This is not a criticism of any of these tools. Debezium's job is to guarantee reliable, ordered delivery of database change events. Fivetran and Airbyte's job is to keep a destination schema synchronized with a source schema so you are not writing and maintaining custom connector code for every system you touch. All three do that job well, and none of them claim to validate business meaning, because that was never in scope.

What they share is a structural definition of correctness: did the row arrive, does the column exist, does the type match what was declared. A value can pass every one of those checks and still be wrong in a way that costs the business money. Rename a field outright and most CDC tooling will flag it, since the column itself changes. Redefine what a field means without touching its name or its type, and that change passes through completely unflagged, every time.

What semantic monitoring adds on top of CDC

This is the layer mmune sits in. It does not replace Debezium, Fivetran, Airbyte, or a custom Kafka Connect setup, and it is not trying to. Those tools should keep doing exactly what they do: move data reliably and adapt to structural change without breaking the pipeline.

mmune watches the values flowing through those pipelines and builds a semantic map of what each field is supposed to mean, not just what type it is declared as. When order_status starts absorbing a category it never used to carry, when a timestamp column's values shift by a consistent offset, or when a field that used to be unique starts producing duplicates under different transaction IDs, that is a pattern a structural schema check will never catch and a semantic watchdog will. When confidence in a proposed fix clears the threshold, mmune applies it automatically, before the bad data reaches your warehouse or your ERP. Every action is logged in an audit trail that is reversible and tied back to its source.

Getting ahead of it

If your team runs CDC through Debezium, Fivetran, Airbyte, or a custom Kafka Connect pipeline, the question worth asking is not whether the pipeline will survive the next schema change. It probably will. The question is whether anyone will notice the data drifting semantically while the pipeline reports success, three weeks before someone downstream builds a report on top of it.

mmune deploys as a read-only overlay above your existing CDC layer, with zero code changes to the pipelines you already run. If you want to see what is moving through yours that your current monitoring is not catching, find your blind spots.