Business Semantics: When Every Dashboard Defines Its Own Revenue

Metric Views compared: Databricks Unity Catalog vs. Snowflake Semantic Views vs. dbt Semantic Layer.

Ask five analysts in the same company what "revenue" means and you will get five answers. One dashboard includes refunds; another excludes them. A third nets out discounts before aggregation; a fourth applies them after. The numbers are all defensible within their local context. None of them match. According to Gartner, poor data quality costs organizations an average of $12.9 million per year [1]. IBM estimates that over a quarter of enterprises lose more than $5 million annually to the same problem [2]. The root cause is not bad data. It is unsynchronized definitions: the same metric, defined independently in every tool that touches it, drifting apart silently until someone notices the numbers disagree and the conversation shifts from "What should we do?" to "Which number is right?" [3].

This is the metric drift problem. Modern BI tools make it trivially easy for any team to build dashboards independently, each with its own filter logic, date-range handling, and aggregation rules [4]. MuleSoft's 2025 Connectivity Benchmark puts the average enterprise at 897 applications [5], and IBM estimates that 68% of enterprise data goes unanalyzed because of the resulting fragmentation [5]. The answer every major data platform has converged on is a semantic layer: define the metric once, in one governed location, and have every downstream consumer read the same definition. The disagreement is over where that definition should live and how it should be governed. Three approaches now compete in production.

What the market offers

Snowflake Semantic Views

Snowflake Semantic Views are schema-level database objects that store business metric definitions directly in Snowflake. You define facts (row-level attributes), metrics (aggregated KPIs like SUM, AVG, COUNT), and dimensions (categorical grouping attributes), bridging the gap between how business users describe data and how it is physically stored [6].

The feature followed a staged rollout. Semantic Views launched in Preview in April 2025 (initially labeled "semantic models") [7]. Core DDL went Generally Available at Snowflake Summit in June 2025 [8]. Derived metrics reached GA on September 30, 2025 [9]. Standard SQL querying -- the ability to SELECT directly from a semantic view without Cortex -- went GA on March 2, 2026 [9]. Semi-additive metrics (`NON ADDITIVE BY`) entered Preview on March 5, 2026 [9].

Authoring options include SQL DDL (`CREATE SEMANTIC VIEW`), Semantic View Autopilot (an AI-assisted wizard in Snowsight), and Semantic Studio with conversational AI assistance [6]. Semantic Views can be queried via standard SELECT statements, Cortex Agents (natural language), and Cortex Analyst, and they can be shared through Snowflake Marketplace [6]. Cortex Analyst reads the semantic view definition and generates SQL against the underlying physical tables, enabling natural-language-to-SQL workflows. Since March 2025, Cortex Analyst supports multiple semantic views in a single query [10].

Snowflake Semantic Views inherit Snowflake's RBAC and access control. They are, however, schema-level objects within Snowflake's environment -- not part of a broader open governance catalog. The definitions exist within Snowflake's perimeter and cannot directly serve external engines without first ingesting the data into Snowflake [5][11].

dbt Semantic Layer (MetricFlow)

The dbt Semantic Layer, powered by MetricFlow, takes a different architectural approach. Metrics are defined in YAML within a dbt project and served through the dbt Cloud Semantic Layer API via JDBC, GraphQL, or direct integrations with tools like Tableau, Hex, and Mode [12]. MetricFlow's core is open source under the Apache 2.0 license [12].

The key value proposition is warehouse portability. dbt metric definitions work against Snowflake, Databricks, BigQuery, Redshift, and other supported warehouses. The tradeoff is infrastructure: dbt Cloud becomes a required intermediary between the definition and the consumer, adding a proxy layer, a separate caching tier, and a dbt Cloud Team or Enterprise subscription [9][13]. For organizations running a single data warehouse, this adds cost and complexity for portability they may not need. Typedef.ai's 2026 comparison concluded that MetricFlow wins for current BI breadth thanks to universal JDBC compatibility, while noting that Snowflake and Databricks are "catching up rapidly via OSI partnerships" [11].

What Databricks ships

Unity Catalog Business Semantics, including Metric Views, reached General Availability on April 2, 2026 [14]. Metric Views are Unity Catalog securable objects that define business KPIs centrally, separating measure definitions from dimensions. You define the metric once -- for example, `SUM(revenue) / COUNT(DISTINCT customer_id)` -- and users can group by any available dimension at query time. The query engine generates the correct computation deterministically [15].

The mechanics work as follows. A Metric View is defined in SQL DDL or via the Catalog Explorer UI with built-in YAML validation. Each metric view carries semantic metadata -- display names, formats, and synonyms -- that makes it interpretable by both humans and AI agents [14]. Definitions are portable across every Databricks consumption surface: AI/BI Dashboards, Genie, Notebooks, SQL applications, and third-party tools connected to Databricks [14]. Measures compose: a `profit` measure can reference `revenue` and `cost` measures, with the engine resolving the dependency graph at query time [15].

Materialization -- pre-computed results with incremental refresh and automatic query rewriting -- is in Public Preview as of the GA date [14]. A point-and-click UI for authoring metric views in Unity Catalog Explorer launched simultaneously in Public Preview [14]. Genie Code, an agentic AI authoring assistant, can bootstrap semantic models, suggest measures, dimensions, and synonyms [14].

Databricks is open-sourcing the core Metric View implementation into Apache Spark, tracked as SPARK-54119, with Unity Catalog OSS v0.5 support on the roadmap [14][16].

The architectural distinction

The structural difference is governance integration. Databricks Metric Views are first-class Unity Catalog objects with the same permissions, lineage tracking, and access control as the data tables they measure. A revenue metric inherits row-level security from its source table, appears in lineage graphs alongside the tables and notebooks that consume it, and is governed by the same Unity Catalog policies that govern every other data asset [14][15]. The metric definition and the data it measures live in the same catalog, under the same governance perimeter.

Snowflake Semantic Views inherit Snowflake's RBAC, but they are schema-level objects without the broader open catalog context. There is no equivalent of cross-platform lineage tracing or a single governance plane that extends beyond Snowflake's boundary [5][6]. dbt's MetricFlow definitions live in YAML files in a dbt project, decoupled from any catalog's governance model. They gain portability at the cost of a separate governance and access-control layer.

The practical implication: in a Databricks environment, adding a Metric View does not add a new governance surface. The metric is governed by the same system that governs the table. In a Snowflake environment, Semantic Views are governed within Snowflake but outside any broader catalog federation. In a dbt environment, metric definitions require their own governance workflow, separate from both the warehouse and the catalog.

We concede

Snowflake's Cortex integration is tighter for natural-language analytics. Cortex Analyst reads Semantic View definitions natively and generates SQL against physical tables, with multi-model support since March 2025 [10]. The Semantic View Autopilot and Semantic Studio authoring tools provide a polished, AI-assisted workflow for non-technical users. For organizations standardized on Snowflake with heavy natural-language BI requirements, this integration is a meaningful advantage.

dbt's warehouse portability is real. For organizations running workloads across multiple warehouses -- Snowflake for some teams, Databricks for others, BigQuery for a third -- dbt's Semantic Layer is the only option that governs metrics across all three from a single definition. Both Databricks Metric Views and Snowflake Semantic Views are structurally bound to their respective platforms [5]. If your organization's data estate spans multiple warehouses, a platform-native semantic layer solves the problem within one boundary while leaving it unsolved across boundaries.

The limits of this argument

Metric View materialization (pre-compute and incremental refresh) remains in Public Preview [14]. Until it reaches GA, query performance for complex metrics at scale depends on the underlying table structure rather than pre-aggregated results. Genie Agent Sharing remains in Beta, meaning agents that include metric views cannot currently be shared through that surface [14].

The Open Semantic Interchange (OSI) initiative, launched by Snowflake with Salesforce and dbt Labs in September 2025, shipped its v0.1 specification under Apache 2.0 in January 2026 and entered the Apache Incubator as Apache Ossie in June 2026 [17][18]. Databricks has joined and is actively contributing [14]. If OSI/Ossie converges on a vendor-neutral standard for metric portability, the governance-integration advantage of any platform-native semantic layer may narrow as definitions become portable across catalogs. That convergence has not happened yet, but the trajectory is worth tracking.

Knowi's 2026 comparison notes that both Databricks Metric Views and Snowflake Semantic Views are "included with" their respective platform pricing but are "still relatively new" and "offer less flexibility than standalone semantic layers" [19]. Cube.dev positions warehouse-native layers as "best for single-platform shops" while arguing that teams with multi-warehouse estates or embedded analytics needs should use a "decoupled layer" [13].

Comparison matrix

The verdict

Every major data platform now agrees that metric definitions belong in a governed layer, not scattered across dashboards. The question is whether that layer should be welded to a catalog (Databricks), native to a warehouse (Snowflake), or decoupled from both (dbt). Databricks Metric Views offer the deepest governance integration -- same catalog, same permissions, same lineage -- and are being open-sourced into the Apache ecosystem. Snowflake Semantic Views offer tight natural-language integration through Cortex and a polished authoring experience. dbt offers the only cross-warehouse portability available today. The right choice depends on whether your organization's primary constraint is governance consistency, AI-assisted analytics, or multi-platform coverage. For single-platform Databricks estates where governance and lineage are the priority, Metric Views remove a layer of metric drift without adding a layer of infrastructure.

Sources

[1] Gartner, "Data Quality," https://www.gartner.com/en/data-analytics/topics/data-quality

[2] IBM, "The Cost of Poor Data Quality," https://www.ibm.com/think/insights/cost-of-poor-data-quality

[3] Data Management Blog, "When Metrics Drift, Trust Breaks," https://www.datamanagementblog.com/metrics-drift-trust-breaks-analytics-ai-need-consistent-semantics/

[4] Colrows, "Why BI Metrics Do Not Match Across Dashboards," https://colrows.com/blogs/why-bi-metrics-do-not-match-across-dashboards/

[5] Acceldata, "How to Fix Conflicting Metrics Across Teams," https://www.acceldata.io/blog/how-to-fix-conflicting-metrics-across-teams-a-practical-guide

[6] Snowflake Documentation, "Semantic Views Overview," https://docs.snowflake.com/en/user-guide/views-semantic/overview

[7] Snowflake Release Notes, "Semantic Views Preview (April 2025)," https://docs.snowflake.com/en/release-notes/2025/other/2025-04-17-semantic-views

[8] Snowflake Summit Announcements, "Semantic Views GA (June 2025)," https://docs.snowflake.com/en/release-notes/2025/june-summit

[9] Paradime.io, "dbt Semantic Layer vs. Snowflake Semantic Views: A Complete Technical Comparison," https://www.paradime.io/blog/dbt-semantic-layer-vs-snowflake-semantic-views-a-complete-technical-comparison

[10] Medium, "Snowflake Cortex Analyst: Semantic View vs. Semantic Model," https://medium.com/@ppritesh/snowflake-cortex-analyst-semantic-view-vs-semantic-model-517f04549b65

[11] Typedef.ai, "MetricFlow vs. Snowflake vs. Databricks: Which Semantic Layer?" https://www.typedef.ai/resources/semantic-layer-metricflow-vs-snowflake-vs-databricks

[12] dbt Labs, "Open Source MetricFlow and Governed Metrics," https://www.getdbt.com/blog/open-source-metricflow-governed-metrics

[13] Cube.dev, "dbt Semantic Layer Alternatives (2026)," https://cube.dev/articles/dbt-semantic-layer-alternatives-2026

[14] Databricks, "Redefining Semantics: The Data Layer for the Future of BI and AI," https://www.databricks.com/blog/redefining-semantics-data-layer-future-bi-and-ai

[15] Databricks Documentation, "Metric Views," https://docs.databricks.com/aws/en/uc-semantics/metric-views/

[16] Apache JIRA, "SPARK-54119," https://issues.apache.org/jira/browse/SPARK-54119

[17] Dev.to, "Meet Apache Ossie: The Open Semantic Interchange Finds Its Home at the ASF," https://dev.to/alexmercedcoder/meet-apache-ossie-the-open-semantic-interchange-finds-its-home-at-the-asf-2mio

[18] dbt Labs, "The OSI Spec Updates," https://www.getdbt.com/blog/the-osi-spec-updates

[19] Knowi, "Best Semantic Layer Tools (2026)," https://www.knowi.com/blog/semantic-layer-tools/