Allow selective approval of individual schema changes during review #74892
Replies: 2 comments
-
|
Hi lukewatters-airbyte, thank you for opening this discussion! This is a well-articulated feature request. The current all-or-nothing behavior for schema change reviews is a meaningful limitation — especially for teams that need to preserve historical columns in destination tables while still accepting new schema additions. The workaround of skipping reviews entirely (and accepting NULLs for removed fields) is clearly not sustainable for production pipelines. Granular, per-change approval in the schema review UI would give users much more control over how their destination schemas evolve, and would help prevent unintended data loss in downstream reporting and analytics workflows. I've escalated this to the internal platform team for review and tracking. I'll follow up shortly with a tracking link. Need more help? Join Airbyte Community Slack for peer support, or if you're a Cloud customer, open a support ticket referencing this URL. |
Beta Was this translation helpful? Give feedback.
-
|
This feature request has been escalated to the internal platform team for tracking and review. Internal Tracking: https://github.com/airbytehq/oncall/issues/11665 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Problem
When Airbyte detects a schema change — such as a column being removed from the source — the schema review process currently applies all changes or none. Accepting the review causes all detected changes to be applied, including column removals, which drops those columns from the destination on the next sync. There is no way to accept certain changes (e.g. new columns) while rejecting others (e.g. column removals).
Describe the solution you'd like
Add granular, per-change approval to the schema review UI. Users should be able to individually accept or reject each detected change — for example, accepting a new column while rejecting a column removal to keep the existing destination column intact.
Describe alternatives you've considered
Not reviewing schema changes at all causes syncs to continue with the old schema, preserving destination columns — but new rows will have NULL values for those fields. This is not a viable long-term workaround.
Additional context
This would allow teams to preserve historical columns in destination tables even when source schemas evolve, preventing disruption to downstream reporting and analytics workflows that depend on those fields.
Beta Was this translation helpful? Give feedback.
All reactions