SemaBridge in the Wild

Enterprise BI investments accumulate years of semantic richness — hundreds of DAX measures, time-intelligence calculations, certified KPI hierarchies, and row-level security roles. When the strategic decision arrives to adopt Snowflake as the primary data cloud — to unlock Cortex AI, natural-language analytics, and Snowflake-native Semantic Views — the semantic layer problem surfaces immediately.

Every business metric, every dimension hierarchy, every governance rule lives in Analysis Services' proprietary format. Recreating it in Snowflake's completely different Semantic View syntax requires manual effort measured in months, not days. When that rebuild is finally complete, two independent semantic layers exist — one in Power BI, one in Snowflake — diverging from the moment the first definition changes.

In multi-platform analytics environments, semantic definitions multiply independently. Engineering and data science teams build their metric layer in Databricks Unity Catalog — sophisticated Metrics Views powering ML pipelines, Genie AI, and operational dashboards. Finance and regulatory reporting teams build theirs in Snowflake Semantic Views. Each team defines every KPI with the confidence that comes from owning their platform.

Both definitions are internally consistent. Neither team is wrong — by their own logic. But the same core business metric, built on the same source tables, returns different results on each platform. At quarter-close, the variance surfaces in reporting. Analysts spend weeks reconciling a gap rooted in a single date-boundary assumption that was never aligned across teams. The discrepancy recurs the following quarter. Trust in the data erodes.

Platform migrations routinely pass technical validation on data completeness, pipeline correctness, and schema fidelity. What standard migration checklists do not capture is the semantic layer. Years of certified metric definitions, dimension hierarchies, governance-approved business logic, and row-level security rules live above the data — not in it. They are invisible to ETL tools and migration validators alike.

On go-live day, the data arrives in the new environment intact. The semantic layer does not. Every BI dashboard that relied on semantic objects breaks simultaneously. Data engineering begins a post-migration rebuild of business logic that should never have been left behind — a process measured in months, not days. The migration succeeds technically while the business runs on pre-migration snapshots waiting for the semantic layer to catch up.

Apache Iceberg resolves the data duplication problem. With Fabric OneLake as the canonical data estate, the same Iceberg tables are accessible via Snowflake External Volumes and Databricks Unity Catalog — three compute engines, one physical copy of the data. The open table format delivers on its architectural promise of a unified, vendor-neutral data layer.

The semantic layer above it does not unify automatically. Each platform team builds independently: Fabric Semantic Models for Power BI consumers, Databricks Metrics Views for ML and data science workflows, Snowflake Semantic Views for finance and operations analytics. Three platforms, three teams, three independent definitions for every core business metric. The physical data contract is unified. The semantic contracts are not — and every cross-platform analysis requires a manual reconciliation step that negates the benefit of the shared data layer entirely.