Metric Views in Unity Catalog: define the KPI once, use it everywhere

In nearly two decades of data engineering, I've learned to recognize a symptom that shows up in almost every company as it grows: the same metric calculated in several different ways. "Revenue" on the executive dashboard doesn't match "revenue" in the finance report, which in turn doesn't match the "revenue" the data science team used to train the churn model. Nobody got it wrong on purpose — each person reimplemented the same logic in a slightly different SQL, and the small divergences (one extra filter here, one missing DISTINCT there) piled up.

Unity Catalog Metric Views, highlighted by Databricks at the Data + AI Summit 2026 as part of the new semantic layer, attack exactly this problem. The idea is simple and powerful: you define the metric once, in a governed way, and every consumer — SQL, BI, API, or AI agent — reads the same definition.

The problem with the traditional view

A plain SQL view solves reuse of the query, but not of the metric. When you write:

CREATE VIEW revenue_by_country AS
SELECT country, SUM(total) AS revenue
FROM sales
GROUP BY country;

you've locked the granularity at creation time. This view only serves revenue by country. If tomorrow someone needs revenue by month, or by product, or by country and month, they'll have to write another view — and that's where definitions start to diverge. The aggregation (SUM(total)) and the dimension (country) are glued to the same object.

A Metric View separates those two things. You define the measure (the calculation) independently from the dimensions (what you group by), and you decide the granularity only at query time.

Step 1 — Define the metric in YAML

A Metric View is declared in YAML and registered in Unity Catalog as if it were a view. In SQL, you wrap the YAML in a CREATE VIEW ... WITH METRICS, with the definition between $$ delimiters:

CREATE VIEW sales.revenue_mv
WITH METRICS
LANGUAGE YAML
AS $$
version: 1.1
source: sales.orders
dimensions:
  - name: country
    expr: country
  - name: month
    expr: date_trunc('MONTH', order_date)
measures:
  - name: revenue
    expr: SUM(total)
  - name: customers
    expr: COUNT(DISTINCT customer_id)
$$;

Notice the structure: source is the origin table (or a query); dimensions are the axes you'll slice by; measures are the aggregated calculations. The definition of revenue as SUM(total) now lives in one place only — Unity Catalog.

Step 2 — Query with MEASURE() and group by any dimension

Here is the practical difference from the traditional view. You query the Metric View with the MEASURE() function and group by any available dimension — the engine generates the correct aggregation on every query:

-- revenue by country
SELECT country, MEASURE(revenue) AS revenue
FROM sales.revenue_mv
GROUP BY country;

-- the SAME metric, now by country and month
SELECT country, month, MEASURE(revenue) AS revenue
FROM sales.revenue_mv
GROUP BY country, month;

There is no second definition of revenue. The calculation rule is the same; only the GROUP BY changes. This is the heart of the semantic layer: the metric is immutable, the granularity is free.

And because the Metric View lives in Unity Catalog, you can also query it programmatically with spark.sql() (in notebooks on DBR 17.2+ or via a SQL warehouse) — always going through MEASURE(). The same number, now available for PySpark pipelines:

df = spark.sql("""
    SELECT country, MEASURE(revenue) AS revenue
    FROM sales.revenue_mv
    GROUP BY country
""")
df.show()

One detail that trips people up: the Metric View only responds through MEASURE(). A SELECT * — or a plain spark.read.table(...).show() — is not supported, precisely because the measure has no predetermined granularity until you tell it what to group by.

Step 3 — One number, consumed everywhere

The strategic gain becomes clear when you look at who consumes the definition. Because it lives in the catalog, the same KPI is read identically by:

• SQL and Warehouses — analysts write queries without reinventing the calculation.
• Power BI and BI tools — the dashboard inherits the official definition, not a copy.
• APIs — applications consume the governed metric behind an endpoint.
• AI agents — and this is the most current point of 2026: when an LLM needs to answer "what was last quarter's revenue?", it queries the official definition instead of improvising a SQL. The semantic layer becomes the grounding that keeps the agent from inventing the calculation.

Governance: the metric inherits Unity Catalog

A detail that data engineers value: because it's a Unity Catalog object, the Metric View inherits the entire governance model — group-based permissions, column masking, lineage, and auditing. You control who can query the metric with the same tools you already use for tables, and you can trace the origin of every number back to the base table. Consistency stops depending on human discipline and becomes guaranteed by the platform.

When to use — and when not

Metric Views shine when the goal is to standardize the core business KPIs — revenue, margin, churn, active users — and to guarantee that every consumer sees the same number. They're the right answer to the classic question "why do these two reports disagree?".

But it's important to be honest about the limits:

• Metric Views don't replace dimensional modeling. They sit on top of tables that are already clean and treated. You still need your ETL, your conformed dimensions, and your fact tables. The Metric View standardizes the final calculation, not the data preparation.
• They're not a shortcut to skip the engineering. If the source table is dirty or badly modeled, the metric will just propagate the problem more consistently.
• The spec is still evolving. The YAML syntax (keys like source, fields — the former dimensions —, measures, filter, joins, window measures) is maturing fast — it's worth checking the official reference before designing anything complex, since new features keep being added.

Conclusion

After years of watching teams argue over which dashboard has the "right" number, it's hard not to see Metric Views as a necessary course correction. The problem was never a lack of SQL — it was too much of it, with the same metric reimplemented dozens of times. Turning the KPI into a governed object, defined once and consumed by SQL, BI, API, and AI agents, is the kind of simplification that gives you back trust in the data.

If, in your company, the word "revenue" means slightly different things depending on who's asking, a Metric Views experiment is worth it. The chance you'll end up deleting duplicated definitions — instead of creating one more — is real.