SQL Database - Source Control

[going_grey]

Hi

I can't find information to confirm the following: (I'll simplify the scenario)

I have a workspace thats connected to an Azure DevOps Repo. It contains a SQL Database with two tables - Table A and Table B. I branched out to a new workspace and droppedTable B.

If I commit, merge back into main and update the "main" workspace, should Table B still exist there?

In my case, Table B still exists. I expected it to be gone. Am I missing anything here?

[stoic-harsh]

Hi @going_grey,

This is expected. Fabric Git sync for database objects (unlike pipeline, notbooks) is intentionally non-destructive, meaning deleting a table's definition file from a branch and merging it back does not trigger a DROP TABLE command. In short, Git only controls the schema definitions, not destructive DDL.

Just FYI, note that Warehouse and SQL Database track full object definitions in Git (Tables, Views, Stored Procedures, Functions), while Lakehouse track only metadata and shortcuts.

That being said, if you find something useful or contrary to these points, please do share so that it benefits us all in such scenarios.

[deborshi_nag · Accepted solution]

Hello @going_grey 

This is expected behaviour. Fabric Git integration only manages artefact definitions and does not reconcile or enforce the physical schema inside a SQL Database or Warehouse. Dropping a table in a branched workspace is a runtime DDL change and isn’t tracked or replayed when you merge and update the main workspace. As a result, existing tables like Table B will remain unless they’re explicitly dropped in that workspace (or via a deployment script). Git sync today is additive and non‑destructive by design.

Fabric Git integration is Source control for the shell of the database, not its contents.

Dropping a table is comparable to:

• Deleting rows inside a lakehouse
• Running TRUNCATE TABLE
• Changing data, not definitions

Those actions are outside Git reconciliation.