Allow Non-Breaking Schema Changes in Fabric CI/CD Deployments for Data Warehouse Objects
Hi,
currently, Microsoft Fabric deployment pipelines can fail when a Data Warehouse deployment contains schema changes such as adding, removing, renaming, or modifying columns in existing tables.
In environments where Data Warehouse tables already exist and CI/CD pipelines are used to automatically promote changes across Development, Test, and Production, this limitation becomes very important.
For example, deployments can fail with errors similar to:
DataLoss: The column is being dropped, data loss could occur.
or
ALTER COLUMN operation is not supported and deployment is blocked.
As a result, even legitimate schema evolution scenarios require manual intervention, preventing fully automated deployments and increasing operational risk.
Requested Improvement
Provide configurable deployment options for Data Warehouse schema changes, such as:
- Allow schema evolution during CI/CD deployments.
- Support automatic handling of column additions, removals, and data type changes when explicitly approved.
- Introduce deployment settings to ignore or accept "data loss" warnings.
- Provide deployment modes similar to DACPAC publishing options available in SQL Server tooling.
- Offer pre-deployment validation and impact analysis without completely blocking the release.
Business Impact
This limitation significantly reduces the effectiveness of Fabric CI/CD pipelines for enterprise environments, where schema changes are a normal part of application and data platform lifecycle management.
Without support for controlled schema evolution:
- Automated releases become unreliable.
- Manual production interventions are required.
- DevOps adoption is slowed down.
- Development, Test, and Production environments can become inconsistent.
Supporting controlled schema changes would greatly improve Fabric's enterprise readiness and align deployment capabilities with modern DataOps and DevOps practices.
Schema evolution should not require manual intervention in enterprise CI/CD deployment pipelines!!
Thank you for your support. I sincerely hope this limitation can be addressed, as it represents a significant challenge for organizations implementing automated CI/CD deployment processes with Microsoft Fabric.
Recent ideas
Power BI Dynamic Subscription Capacity Consumption and Recipient Processing
Issue: The concern is that the dynamic subscription workload can consume a significant amount of capacity when generating and distributing personalized report outputs. This creates a scalability conc...vivek123443 hours agoMicrosoft EmployeeNew4Views0likes0CommentsSchedule pipeline as Service Principal
It would be beneficial to be able to specify an anonymous sp or user account while creating a schedule to run a pipeline directly in the Fabric GUI. This is currently only possible via the rest api a...Juriaan809112554 hours agoNew MemberNew3Views0likes0CommentsImprove Databricks Native SQL Development Experience in Power BI
As organizations increasingly adopt Databricks as their primary data platform, Power BI remains a preferred tool for semantic modeling, visualization, executive reporting, and self-service analytics....Applsfan5 hours agoNew MemberNew5Views0likes0CommentsFabric Workspace Operator Role for Pipeline Monitoring and Rerun Operations
Many organizations have dedicated production support and operations teams responsible for monitoring Microsoft Fabric pipelines and responding to failures. Currently, the available workspace roles ar...cmukul0075 hours agoRegular VisitorNew67Views4likes1CommentPower BI Admin to Disable the New Ribbon Preview & Control Rep Toolbar Visibility at Tenant Level
Allow Power BI Administrators to Disable the New Ribbon Preview and Control Report Toolbar Visibility at Tenant Level It takes too much real estate and by default users with low maturity leaves it a...icassiem6 hours agoPost ProdigyNew33Views5likes1Comment