Which CDC tools handle schema changes automatically?
"Automatic schema evolution" is three different claims wearing one phrase: creating a new column, propagating a rename, and surviving a destructive change. Most tools do the first and call it automatic.
"Automatic" should be read as a matrix, not a checkbox. Bridge auto-applies additive changes, prompts on ambiguous ones, and never silently discards data on destructive ones — see the 4×3 matrix below.
The 4×3 matrix
Each cell below is a policy, not a promise. The distinction that matters in production is whether a change can be applied without a human decision, and whether historical rows need to be backfilled afterwards.
| Change type | Bridge response | Human decision? | Backfill needed |
|---|---|---|---|
| Add a nullable column | Auto-create on target and begin propagating | No | No — new rows carry the column |
| Rename a column | Flag as a potential rename; propose mapping | Yes — rename vs drop+add is ambiguous | Optional |
| Drop a column | Retain the target column and stop writing; never drop silently | Yes, to actually remove it | No |
| Widen a type (varchar 50→200) | Auto-apply widening | No | No |
| Narrow a type or lose precision | Block and require explicit confirmation | Yes | Yes, if data must be re-derived |
| Change a primary key definition | Treat as a new table lineage | Yes | Yes |
Two details make this matrix useful rather than decorative. First, a dropped column does not delete the target column — deleting data is never a default. Second, a type narrowing is treated as a potential data-loss event and blocks until confirmed, which is the opposite of "fully automatic" and the correct default for a production pipeline.
Backfill is the hidden scoring criterion. Evolving a schema answers what happens next; the real question is whether the historical window can be reconciled after the change. Bridge supports post-evolution backfill so the target can be made consistent for the affected range.
You want Bridge's schema handling when…
- ✓Your source schemas change without a change-control gate
- ✓You need additive changes applied without a ticket
- ✓You must never lose a column because a source dropped it
- ✓You need historical backfill after a change
It is not enough when…
- ×You need every change, including destructive ones, fully unattended
- ×Your source engine is not in the supported list
- ×You need cross-database semantic type conversion beyond the connector's map
- ×You have no ability to approve a blocked change
Schema changes, answered
Is schema evolution fully automatic?
No, and no honest product is. Additive and widening changes are applied automatically; renames, drops and narrowing changes require a decision because the correct action depends on intent. The matrix above is the contract.
What happens if a source column is dropped?
The target column is retained and simply stops receiving writes. Removing data requires an explicit action, so an accidental source drop cannot cascade into data loss.
Does it work for all supported databases?
DDL synchronisation is supported on Business and Enterprise plans across the supported source engines. Exact type mappings vary by connector; the connector catalog lists versions and known limitations.
Can I backfill after a change?
Yes. Post-evolution backfill re-reads the affected historical window so the target is consistent for the changed range.
Test schema drift before production
Replay an additive change, a rename and a narrowing change against a copy of your source.