Databricks metric views are Unity Catalog objects that define business metrics once, in YAML, and let anyone query them at any grain with the MEASURE() function. They’re the core of the Databricks semantic layer, now marketed as Unity Catalog Business Semantics. Genie, AI/BI dashboards, SQL users, and external BI tools all read from the same definitions.

Metric views reached general availability on April 2, 2026, and Databricks is open-sourcing the core implementation into Apache Spark. Since then, window measures have gone GA, Genie Spaces were renamed Genie Agents, and Microsoft pulled a key Power BI integration. This guide covers the syntax, querying, Genie, BI tools, materialization, and the limitations practitioners actually hit, plus an honest comparison with Snowflake semantic views.

What Are Databricks Metric Views?

A metric view is “the core implementation of Unity Catalog semantics,” separating measure definitions from the fields (also called dimensions) you group by. You write it in YAML, wrap it in a CREATE VIEW statement, and Unity Catalog governs it like any other securable object.

Metric View vs Standard View

That last row is the real value, and it’s the core promise of any metrics layer. A standard view that pre-computes “revenue per customer” by month gives the wrong answer if someone averages it by quarter. A metric view recomputes the ratio correctly for whatever grain is requested.

Where Metric Views Fit in Unity Catalog Semantics

Unity Catalog Semantics has four parts: metric views, Domains, Pages (beta), and certification. Databricks says together they make up “the human-modeled layer of the Genie Ontology,” which Genie One combines with context it infers automatically (more on that in our data ontology guide).

Is Databricks a Semantic Layer?

Databricks itself is a data and AI platform, not a semantic layer. Its native semantic layer is Unity Catalog metric views: governed YAML definitions of measures and dimensions that Genie, AI/BI dashboards, SQL, and BI tools query with MEASURE(). It only covers data registered in Unity Catalog.

In the medallion architecture, bronze tables hold raw data, silver tables hold cleaned and conformed data, and gold tables hold denormalized, read-optimized data for reporting. Metric views sit on top of gold (or silver) tables. They don’t store data; they define how to compute it.

Requirements Before You Start

• Unity Catalog is required. Metric views are Unity Catalog securables.

• Compute: Databricks Runtime 16.4+ or a SQL warehouse. Many features need newer versions: snowflake-schema joins and agent metadata need DBR 17.3, one-to-many joins and agg() need 18.1, and parameters need 18.2 (feature availability).

• Privileges to create: SELECT on the source, CREATE TABLE and USE SCHEMA on the schema, and USE CATALOG on the catalog.

• Privileges to query: SELECT on the metric view.

How to Create a Metric View

The YAML Anatomy

A Complete Example

This example from the Databricks docs uses the samples.tpch data that exists in every workspace, so you can run it as-is:

CREATE OR REPLACE VIEW orders_metric_view WITH METRICS LANGUAGE YAML AS
$$
  version: 1.1
  comment: "Orders KPIs for sales analysis"
  source: samples.tpch.orders
  joins:
    - name: customer
      source: samples.tpch.customer
      'on': source.o_custkey = customer.c_custkey
      rely:
        at_most_one_match: true
  filter: source.o_orderdate > '1990-01-01'
  fields:
    - name: Order Month
      expr: DATE_TRUNC('MONTH', source.o_orderdate)
    - name: Order Status
      expr: |-
        CASE
          WHEN source.o_orderstatus = 'O' THEN 'Open'
          WHEN source.o_orderstatus = 'P' THEN 'Processing'
          WHEN source.o_orderstatus = 'F' THEN 'Fulfilled'
        END
    - name: Market Segment
      expr: customer.c_mktsegment
  measures:
    - name: Order Count
      expr: COUNT(1)
    - name: Total Revenue
      expr: SUM(source.o_totalprice)
    - name: Total Revenue per Customer
      expr: SUM(source.o_totalprice) / COUNT(DISTINCT source.o_custkey)

CREATE OR REPLACE VIEW orders_metric_view WITH METRICS LANGUAGE YAML AS
$$
  version: 1.1
  comment: "Orders KPIs for sales analysis"
  source: samples.tpch.orders
  joins:
    - name: customer
      source: samples.tpch.customer
      'on': source.o_custkey = customer.c_custkey
      rely:
        at_most_one_match: true
  filter: source.o_orderdate > '1990-01-01'
  fields:
    - name: Order Month
      expr: DATE_TRUNC('MONTH', source.o_orderdate)
    - name: Order Status
      expr: |-
        CASE
          WHEN source.o_orderstatus = 'O' THEN 'Open'
          WHEN source.o_orderstatus = 'P' THEN 'Processing'
          WHEN source.o_orderstatus = 'F' THEN 'Fulfilled'
        END
    - name: Market Segment
      expr: customer.c_mktsegment
  measures:
    - name: Order Count
      expr: COUNT(1)
    - name: Total Revenue
      expr: SUM(source.o_totalprice)
    - name: Total Revenue per Customer
      expr: SUM(source.o_totalprice) / COUNT(DISTINCT source.o_custkey)

CREATE OR REPLACE VIEW orders_metric_view WITH METRICS LANGUAGE YAML AS
$$
  version: 1.1
  comment: "Orders KPIs for sales analysis"
  source: samples.tpch.orders
  joins:
    - name: customer
      source: samples.tpch.customer
      'on': source.o_custkey = customer.c_custkey
      rely:
        at_most_one_match: true
  filter: source.o_orderdate > '1990-01-01'
  fields:
    - name: Order Month
      expr: DATE_TRUNC('MONTH', source.o_orderdate)
    - name: Order Status
      expr: |-
        CASE
          WHEN source.o_orderstatus = 'O' THEN 'Open'
          WHEN source.o_orderstatus = 'P' THEN 'Processing'
          WHEN source.o_orderstatus = 'F' THEN 'Fulfilled'
        END
    - name: Market Segment
      expr: customer.c_mktsegment
  measures:
    - name: Order Count
      expr: COUNT(1)
    - name: Total Revenue
      expr: SUM(source.o_totalprice)
    - name: Total Revenue per Customer
      expr: SUM(source.o_totalprice) / COUNT(DISTINCT source.o_custkey)

CREATE OR REPLACE VIEW orders_metric_view WITH METRICS LANGUAGE YAML AS
$$
  version: 1.1
  comment: "Orders KPIs for sales analysis"
  source: samples.tpch.orders
  joins:
    - name: customer
      source: samples.tpch.customer
      'on': source.o_custkey = customer.c_custkey
      rely:
        at_most_one_match: true
  filter: source.o_orderdate > '1990-01-01'
  fields:
    - name: Order Month
      expr: DATE_TRUNC('MONTH', source.o_orderdate)
    - name: Order Status
      expr: |-
        CASE
          WHEN source.o_orderstatus = 'O' THEN 'Open'
          WHEN source.o_orderstatus = 'P' THEN 'Processing'
          WHEN source.o_orderstatus = 'F' THEN 'Fulfilled'
        END
    - name: Market Segment
      expr: customer.c_mktsegment
  measures:
    - name: Order Count
      expr: COUNT(1)
    - name: Total Revenue
      expr: SUM(source.o_totalprice)
    - name: Total Revenue per Customer
      expr: SUM(source.o_totalprice) / COUNT(DISTINCT source.o_custkey)

The CASE expression is a good habit. It turns raw codes into business labels once, so nobody downstream has to remember that F means fulfilled.

Other Ways to Create Metric Views

You can also build metric views in Catalog Explorer’s point-and-click editor, or with Genie Code. Genie Code’s /importBI skill converts Tableau workbooks and Power BI .pbit and .tmdl files into metric view definitions.

Joins and a Silent-Correctness Gotcha

Joins are LEFT OUTER, and a metric view only joins the tables a query actually needs. Watch two settings. If a join is really many-to-many, “the first matching row from the joined dimension table is selected” with no error. And at_most_one_match: true isn’t validated at runtime, so if it’s wrong, SUM and COUNT measures return incorrect results. Check join cardinality before you set it.

How to Query a Metric View

SELECT
  `Order Month`,
  `Order Status`,
  MEASURE(`Total Revenue`)
FROM orders_metric_view
GROUP BY ALL
ORDER BY `Order Month

SELECT
  `Order Month`,
  `Order Status`,
  MEASURE(`Total Revenue`)
FROM orders_metric_view
GROUP BY ALL
ORDER BY `Order Month

SELECT
  `Order Month`,
  `Order Status`,
  MEASURE(`Total Revenue`)
FROM orders_metric_view
GROUP BY ALL
ORDER BY `Order Month

SELECT
  `Order Month`,
  `Order Status`,
  MEASURE(`Total Revenue`)
FROM orders_metric_view
GROUP BY ALL
ORDER BY `Order Month

Rules to know:

• Every measure must be wrapped in MEASURE() (or agg() on DBR 18.1+).

• SELECT * isn’t supported. List columns explicitly.

• MEASURE() can take a filter on DBR 18.1+: MEASURE(Total Revenue) FILTER (WHERE ...).

• Joining a metric view to other tables at query time isn’t supported. Aggregate it in a CTE first, then join the CTE.

AI/BI dashboards apply MEASURE() automatically, and you can also query metric views from Genie, alerts, JDBC/ODBC, the Excel add-in, and Google Sheets.

Advanced Measures

• Window measures (GA October 6, 2026): Trailing, leading, cumulative, and offset windows, e.g. a 7-day rolling count of customers with range: trailing 7 day.

• Semi-additive measures: semiadditive: last takes the last balance over time while summing across customers, which is the right behavior for account balances or inventory.

• Composed measures: Reference other measures, e.g. MEASURE(total_revenue) / MEASURE(order_count). Databricks’ modeling guidance is to model atomic measures first.

• Metric views on metric views: One metric view can be the source of another.

Agent Metadata and Genie

Spec 1.1 adds agent metadata: display_name, up to 10 synonyms, and a format (currency, percentage, date, and others) on each field and measure. It helps Genie interpret questions and present answers correctly. Good column descriptions matter just as much; see our data dictionary guide.

Databricks says metric views are “particularly effective for Genie Agents” because they pre-define metrics, dimensions, and aggregations. A few things to know:

• A Genie Agent can use up to 50 tables, views, or metric views.

• Verified answers live in the Genie Agent, not the metric view. Trusted assets (parameterized example SQL and UC functions), instructions, and knowledge snippets are configured per agent. That’s different from Snowflake, which stores verified queries inside the semantic view.

• Genie One brings Genie Agents, dashboards, and metric views into one chat, and its MCP server lets Claude, ChatGPT, or Cursor query Genie under Unity Catalog permissions.

Materialization

Metric views can pre-compute aggregates through a managed Lakeflow pipeline of materialized views. The optimizer then rewrites queries to use the best match. iFood reports queries running “up to 10x” faster. Know the constraints before you rely on it:

• It requires serverless compute and DBR 17.3+.

• It’s blocked if the view or any source table uses row filters, column masks, or ABAC policies.

• Rewrite mode is “relaxed,” so the optimizer may serve a materialization without checking freshness.

• Parameterized metric views can’t be materialized.

Materialization was in public preview as of mid-2026; check the materialization docs for current status.

Using Metric Views in Power BI, Tableau, and Other BI Tools

This is where most practitioner frustration lives. Databricks documents five connection patterns: import definitions with Genie Code, custom SQL with MEASURE(), wrapper views, BI compatibility mode (beta), and built-in partner integrations.

• Power BI: Microsoft removed the metric view BI compatibility option from the Databricks connector in April 2026, and reports that used it stopped working. The workaround is a native query with MEASURE() in DirectQuery mode. One r/databricks thread evaluating a migration from Power BI semantic models describes “hitting roadblocks.”

• Tableau: Custom SQL with MEASURE() or compatibility mode works today. Native “delegated semantics” support is expected in late 2026.

• BI compatibility mode caveats: Measures must be aggregated with SUM (AVG shows 1.0), and grand totals of non-additive measures can be wrong.

• Partners: Sigma, Hex, Omni, and ThoughtSpot have announced integrations, and Atlan, Collibra, and Monte Carlo sync metadata.

Limitations of Databricks Metric Views

1. Unity Catalog and DBR 16.4+ are required, and many features need DBR 17.3–18.2.

2. No query-time joins, no SELECT *, and MEASURE() can’t be used with OVER.

3. ALTER VIEW replaces the entire YAML, and only the owner can edit.

4. Many-to-many joins silently take the first match.

5. Materialization doesn’t work with row filters, masks, or ABAC.

6. Power BI support is limited to native-query workarounds.

7. Genie Agents cap at 50 data objects, and verified answers are scoped per agent.

8. The spec is still evolving: dimensions became fields, and saving with spec 1.1 strips # comments.

Databricks Metric Views vs Snowflake Semantic Views

Both platforms are members of Apache Ossie (formerly the Open Semantic Interchange), which aims to make definitions portable between them. Until that’s real, each semantic layer only governs data on its own platform. Our semantic layer tools comparison covers the cross-platform options. For the Snowflake side, see our guide to Snowflake semantic views.

Best Practices

• Model atomic measures first, then compose ratios and derived metrics from them.

• Translate codes into business labels with CASE in field expressions.

• Use one metric view per business domain, with clear names and descriptions.

• Verify join cardinality before setting at_most_one_match.

• Add agent metadata (display names, formats, a few synonyms) on spec 1.1.

When Warehouse-Native Semantics Aren’t Enough

If your data lives in Databricks and your users work in Genie and AI/BI dashboards, metric views are the right foundation. The limits appear in mixed estates. Power BI-heavy organizations are waiting on Microsoft. Data in Postgres or Snowflake is out of reach, which is where warehouse-agnostic options like the dbt Semantic Layer or Cube’s semantic layer come in. And an agent’s context layer ends up split across Unity Catalog definitions, per-agent instructions, and Pages.

Don’t Have a Semantic Layer Yet? Start Here

Upsolve Data Models gives analytics agents governed context without requiring a semantic layer first, across Databricks and 30+ other SQL sources:

• Register tables with descriptions, types, and keys.

• Encode canonical definitions in one versioned system prompt that every agent surface shares.

• Mark columns as selectable so allowed values are pre-cached nightly.

• Enforce permissions deterministically, never delegated to the agent.

Then deploy the same agent to Slack, Teams, Claude, ChatGPT, or your product, with one set of definitions behind every answer.

Frequently Asked Questions

Is Databricks a semantic layer?

Databricks is a data platform, but it includes a native semantic layer: Unity Catalog metric views, part of Unity Catalog Semantics (GA April 2026). They define measures and dimensions in YAML for data registered in Unity Catalog.

How do you query a metric view in Databricks?

Select fields and wrap each measure in MEASURE(), then GROUP BY ALL. For example: SELECT Order Month, MEASURE(Total Revenue) FROM orders_metric_view GROUP BY ALL. SELECT * and query-time joins aren’t supported.

Do Databricks metric views work with Power BI?

Only with workarounds. Microsoft removed the metric view BI compatibility option from the Power BI connector in April 2026. The recommended approach is a native query using MEASURE() in DirectQuery mode, or wrapper views.

Are Databricks metric views free?

Yes, in the sense that Databricks says Unity Catalog Semantics is “free and included as part of Unity Catalog.” You pay for the compute that runs queries and, if you use materialization, for the serverless pipelines and storage.

What is the difference between a metric view and a regular view in Databricks?

A regular view fixes its aggregation and grouping when it’s created. A metric view separates measures from fields, so users can group by any defined field at query time, and ratios and distinct counts compute correctly at every grain.

What are the best practices for modeling metric views in Databricks?

Start with atomic measures, compose complex metrics from them, map codes to readable labels, keep one domain per metric view, verify join cardinality, and add agent metadata so Genie interprets questions correctly.

Sources

1. Databricks: Redefining Semantics in the Data Layer (GA announcement, Apr 2, 2026). https://www.databricks.com/blog/redefining-semantics-data-layer-future-bi-and-ai

2. Databricks Docs: Unity Catalog metric views. https://docs.databricks.com/aws/en/uc-semantics/metric-views/

3. Databricks Docs: Unity Catalog semantics. https://docs.databricks.com/aws/en/uc-semantics/

4. Databricks Docs: Create a metric view. https://docs.databricks.com/aws/en/uc-semantics/metric-views/create

5. Databricks Docs: Metric view YAML reference. https://docs.databricks.com/aws/en/uc-semantics/metric-views/yaml-reference

6. Databricks Docs: Feature availability. https://docs.databricks.com/aws/en/uc-semantics/metric-views/feature-availability

7. Databricks Docs: Basic modeling. https://docs.databricks.com/aws/en/uc-semantics/metric-views/basic-modeling

8. Databricks Docs: Agent metadata. https://docs.databricks.com/aws/en/uc-semantics/agent-metadata

9. Databricks Docs: Genie Agents best practices. https://docs.databricks.com/aws/en/genie-agents/best-practices

10. Databricks Docs: Materialization for metric views. https://docs.databricks.com/aws/en/uc-semantics/metric-views/materialization

11. Databricks Docs: Use metric views with BI tools. https://docs.databricks.com/aws/en/uc-semantics/metric-views/bi-tools

12. Databricks Docs: Power BI. https://docs.databricks.com/aws/en/partners/bi/power-bi/

13. Databricks: Medallion architecture glossary. https://www.databricks.com/glossary/medallion-architecture

14. Reddit r/databricks: Is it worth it? Metric views + PBI. https://www.reddit.com/r/databricks/comments/1v8pig7/is_it_worth_it_metric_views_pbi/

15. Apache Ossie: Project home. https://ossie.apache.org/

16. Upsolve AI: Data Models. https://upsolve.ai/features/data-models