How are you detecting drift between Fabric environments?

Hi hijesh​,

I like the idea, especially because deployment success does not necessarily mean every environment is still identical afterward.

For Fabric Warehouses, I would use Git integration and deployment pipelines as the source-of-truth layer, then use a drift dashboard like yours as the monitoring layer.

Microsoft’s Warehouse Git integration stores the schema as a database project in Git, so commits become the expected definition of the warehouse.

The Warehouse deployment pipeline then uses DacFx to compare the source and target schemas before deployment and shows the actual object-level differences.

One interesting limitation is that deployment pipelines intentionally do not drop objects that exist only in the target by default. Microsoft notes that a deployment can therefore succeed while the target still differs from the source.

That is exactly where I think your approach adds value.

I would compare three states:

Git definition
→ what should exist

Deployment pipeline comparison
→ what is about to change

Live warehouse comparison/history
→ what actually exists in DEV/UAT/PREPROD/PROD

That would make direct changes in PROD, skipped objects, missing promotions and environment-specific drift much easier to detect.

For me, the most useful alert would probably be:

live PROD definition
≠ approved Git commit / promoted version

rather than only comparing PROD with DEV, because DEV may legitimately contain work that has not been approved for production yet.

So I would keep the dashboard, but anchor the comparison to Git/deployment history where possible. That gives you both the operational visibility you built and a clear source of truth for explaining why environments differ.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.

Hi hijesh,

Nice idea. Drift is easy to miss when people can still change PROD directly. A few things that have worked for me and might fit into your tool:

Compare hashes first, text second. One query per environment gives a fingerprint of every view, procedure and function, and only the objects whose hash differs need a full text diff:

SELECT s.name AS schema_name, o.name AS object_name, o.type_desc,
       HASHBYTES('SHA2_256', m.definition) AS definition_hash,
       o.modify_date
FROM sys.sql_modules AS m
JOIN sys.objects AS o ON o.object_id = m.object_id
JOIN sys.schemas AS s ON s.schema_id = o.schema_id;

• Tables need their own check. They have no entry in sys.sql_modules, so compare INFORMATION_SCHEMA.COLUMNS (column name, data type, length, nullability) per table instead.
• Use modify_date to spot direct changes. An object in PROD with a newer modify_date than your last deployment run was changed by hand.
• Git as the reference. If the warehouses are connected to Git, the repo holds the version that passed review, so comparing each environment with the branch it was deployed from shows both "not promoted yet" and "changed in place".

Are you planning to include security (roles and GRANTs) as well? In my experience that's where environments drift the most.