What "automatic schema evolution" actually means: a 4×3 matrix
The phrase is used to mean three different things. Sorting them into a matrix is the fastest way to find out whether a vendor's claim survives a schema change in production.
Engineering · 2026-11-03 · Sumeta engineering
"Automatic" is not one behaviour. Additive changes can be applied without a human; renames are ambiguous; destructive changes must not be automatic. A vendor that claims all three are automatic is describing something it should not do.
Three meanings wearing one phrase
- Additive. A new nullable column appears on the target and new rows carry it. This can and should be automatic.
- Ambiguous. A rename is indistinguishable from a drop plus an add when read from the log alone. Acting automatically risks either duplicating data or losing it.
- Destructive. Dropping a column, narrowing a type, or changing a key. Automating this is how pipelines delete production data at 3am.
Most "fully automatic" claims cover the first and quietly skip the second and third.
The matrix
| Change | Automatic? | Correct default behaviour | Backfill |
|---|---|---|---|
| Add nullable column | Yes | Create on target; propagate new rows | No |
| Add column with default | Yes | Create; default applies to new rows | Optional |
| Rename column | No — confirm | Propose a mapping; wait for a decision | Optional |
| Drop column | No | Retain target column; stop writing | Not applicable |
| Widen type | Yes | Apply widening | No |
| Narrow type | No — block | Block until confirmed | Yes, if re-derived |
| Change primary key | No | Treat as new lineage | Yes |
The unusual defaults are the ones worth checking in a POC: drop does not delete, narrowing blocks, and rename asks. Each of those is a deliberate refusal to automate something that can lose data.
Why backfill is the hidden question
Evolving a schema answers what happens to the next row. It says nothing about the historical window. If a column was added on Tuesday, every row written before Tuesday lacks it, and a downstream model that assumes completeness will be wrong for weeks.
Post-evolution backfill re-reads the affected range so the seam closes. The constraint is the same as any recovery: it works only if the required log is still retained. A change that happened before your retention horizon must be reconciled from a snapshot instead.
How to test it in an hour
| Test | Action | Pass condition |
|---|---|---|
| Additive | Add a nullable column, insert rows | Column appears; no stop; no manual step |
| Rename | Rename a column | Pipeline flags and waits; no duplicate column |
| Drop | Drop a column | Target column retained; no data loss |
| Narrow | Reduce varchar length | Pipeline blocks with a clear message |
| Backfill | Approve a change, request backfill | Historical range reconciled |
Break a schema on purpose
Run the five tests against a copy of your source and watch what the pipeline actually does.