Schema evolution: the 4×3 matrix
Which schema changes are applied automatically, which require a decision, and what happens to historical data afterwards. This page is the contract behind the phrase "automatic schema evolution".
Docs · Reference · Updated 2026-11-03 · Applies to current Bridge releases
Definition
Schema evolution is the set of policies a pipeline applies when a source table's structure changes: creating, renaming or removing columns, and widening or narrowing types, without breaking the target or losing data.
The matrix
| Change | Automatic? | Bridge behaviour | Backfill |
|---|---|---|---|
| Add nullable column | Yes | Target column created; new rows propagate immediately | Not required |
| Add column with default | Yes | Column created; default applied to new rows only | Optional for historical rows |
| Rename column | No — confirm | Detected as possible rename; proposes mapping before acting | Optional |
| Drop column | No | Target column retained, writes stop; never dropped silently | Not applicable |
| Widen type (varchar 50→200) | Yes | Applied automatically | Not required |
| Narrow type / precision loss | No — block | Pipeline blocks until confirmed | Required if data must be re-derived |
| Change primary key | No | Treated as new lineage; requires explicit setup | Yes |
Three defaults are worth stating plainly because they are unusual:
- Drop never deletes. A source drop stops writes to the target column; removing data is a separate, explicit action.
- Narrowing blocks. Anything that can lose precision stops the pipeline rather than applying a lossy cast.
- Rename is a decision. A rename and a drop-plus-add are indistinguishable from the log alone, so the pipeline asks instead of guessing.
Backfill after a change
Evolving a schema answers "what happens to new rows". The harder question is whether the historical window is still consistent. After an approved change Bridge can re-read the affected range and reconcile the target, so a schema change does not leave a permanent seam in the data.
Backfill is bounded by the same log retention window as normal recovery. If the change happened before your retention horizon, the historical range cannot be recovered from logs and must come from a snapshot instead.
Verifying it in a POC
| Test | What to do | Pass condition |
|---|---|---|
| Additive | Add a nullable column and insert rows | Column appears, no pipeline stop, no manual step |
| Rename | Rename a column in the source | Pipeline flags it and waits rather than duplicating |
| Drop | Drop a column in the source | Target column retained; no data loss |
| Narrowing | Reduce a varchar length | Pipeline blocks with a clear message |
| Backfill | Approve a change, then request backfill | Historical rows reconciled for the affected range |
Schema evolution questions
Does DDL sync cost extra?
DDL synchronisation is included on Business and Enterprise plans; it is not a per-change charge.
Can I force a destructive change?
Yes, after explicit confirmation. The default is to block; nothing destructive is applied without an action.
Is schema evolution available on all connectors?
It applies to the database connectors that report schema metadata through their log or catalog. File and API sources use inference and follow a different path.
How is backfill different from a re-sync?
Backfill re-reads a bounded historical range to reconcile a known change. A re-sync rebuilds the whole target.