PATTERN Cited by 1 source
Additive-only schema evolution¶
Pattern¶
Restrict automated schema evolution to additive changes only (add columns, widen numeric precision). All non-additive changes (type narrowing, renames, primary key changes, lossy conversions) require coordinated manual migration or full re-onboarding outside the automation workflow.
Rationale¶
In a distributed CDC pipeline with multiple independent deployment cadences:
- Additive changes are backward-compatible by construction (old code ignores new fields)
- No historical replay or data rewriting needed
- No ambiguity in interpretation (a new column is unambiguously new)
- Automation can be safe without human judgment in the loop
Non-additive changes are inherently ambiguous (is a textual diff a rename? a drop-and-add?) and require semantic understanding that automation cannot safely provide.
Guard mechanism¶
Pinterest runs automated schema-change PR checks to prevent unsupported changes from entering the pipeline accidentally — the guardrail rejects PRs containing non-additive modifications before they reach the automation.
Seen in¶
- sources/2026-06-24-pinterest-automated-schema-evolution-in-pinterests-next-generation-db — Pinterest deliberately restricts automation to additive changes, with clear documentation of which changes require manual migration paths