Databricks metric views, compared with a semantic layer in code
How Unity Catalog metric views are defined and queried, what reads them, how governance applies, and how the same model looks when it lives in your application code instead of the lakehouse.
Definition
What is a Databricks metric view?
A metric view is a Unity Catalog view, defined in YAML, that keeps measures separate from the fields you group by. You define revenue once; a query asks for revenue by customer country or by month, and Databricks computes it correctly for that grouping at query time.
Databricks calls metric views the core of Unity Catalog business semantics. Dashboards, Genie and SQL users read the same definitions, governed by Unity Catalog privileges. The core implementation is now part of Apache Spark 4.2.
How it works
A YAML definition, queried with MEASURE()
The YAML names a source (a table, view, metric view or SQL query), an optional filter applied to every query, many-to-one joins, the fields you group by and the measures. Measures can carry a window, such as a trailing seven days, and the view can declare a materialization that Databricks keeps up to date and rewrites queries to use.
Creating one needs SELECT on the source, CREATE TABLE and USE SCHEMA on the target schema, and a warehouse or cluster to run on. You can also build it in Catalog Explorer under Create, then Metric view.
Facts to know
Where Databricks metric views stand in late 2026
Status
Generally available since April 2, 2026. Relationships between metric views are in beta and need Runtime 19. Some YAML features need Runtime 17.3 to 19.
Open source
The core shipped in Apache Spark 4.2.0 as CREATE VIEW ... WITH METRICS. Materialization, Genie and Catalog Explorer authoring stay in Databricks.
BI tools
Power BI, Tableau and Sigma query metric views through custom or native SQL. Native integrations from Hex, Sigma, Omni and others were announced at GA; ThoughtSpot and Tableau are planned.
Joins
Joins must be many-to-one; one-to-many needs Runtime 18.1. For many-to-many data, the first matching row is used, and joined tables cannot have ARRAY or MAP columns.
The same model in code
The orders metric view as a code-defined semantic layer
The same source, join, fields and measures as hypequery datasets, plus a trailing seven-day revenue window. The test-order exclusion becomes a filter on each measure, and per-customer access comes from a tenant key filled by your backend, not from catalog privileges.
| Databricks metric view | hypequery | Notes |
|---|---|---|
source | Dataset source | A table or view. Point it at a view for a query-shaped source. |
joins (many-to-one) | belongsTo, hasOne | To-one joins, one hop deep; hasMany is metadata only. |
fields (formerly dimensions) | Dimensions | Time grains come from timeKey and by instead of one field per grain. |
measures | measure.sum(), count(), derived() | Queries are checked against declared measure names at compile time; backing column names are checked when the query runs. |
Measure window | measure.trailing(), toDate(), cumulative() | Trailing windows, to-date periods and running totals. |
Top-level filter | Measure filters, or a filtered view as the source | Datasets have no single dataset-wide filter. |
materialization | ClickHouse materialized views or projections | Defined in ClickHouse; point a dataset at the rollup table. |
MEASURE() | analytics.execute() | Or the Serve HTTP API, React hooks and MCP. |
| Unity Catalog privileges | tenantKey | Filled from the authenticated session on each request. |
Comparison
Databricks metric views vs a semantic layer in code
Checked against Databricks’ docs and announcements on November 10, 2026.
| Databricks metric views | Code-defined (hypequery) | |
|---|---|---|
| Where definitions live | A Unity Catalog view, defined in YAML through SQL DDL or Catalog Explorer | TypeScript or Python files in your application repo |
| How consumers query | SQL with MEASURE() from the SQL editor, notebooks, AI/BI dashboards, Genie and alerts; BI tools through SQL or native integrations | Direct calls in your backend, a typed HTTP API, React hooks and an MCP server |
| Databases | Databricks. The core also ships in Apache Spark 4.2 | ClickHouse |
| Per-customer data | Anyone with SELECT on the view can query it. Row filters and column masks cannot be set on a view, and a view over filtered or masked tables cannot be materialized | A tenant key on the dataset, filled from the authenticated session; a query without it fails |
| Query restrictions | No SELECT *, and no direct joins with other tables | Joins are declared on the dataset; the query names fields |
| Change process | CREATE OR REPLACE or ALTER VIEW, which replaces the whole YAML | A pull request, reviewed and deployed with the code that uses it |
| Pre-aggregation | A materialization block, built by a managed Lakeflow pipeline and billed as serverless DBUs | ClickHouse materialized views or projections you define |
| Price | No separate charge is documented; queries use your compute | Apache 2.0, free; runs on your ClickHouse |
An honest answer
When a Databricks metric view is the better choice
- Your data is in the lakehouse, governed by Unity Catalog, and that is where metrics should live.
- Genie, AI/BI dashboards and SQL users are the consumers.
- You want Databricks to maintain pre-aggregations for you through materialization.
- You want a definition that also runs on open-source Apache Spark.
A code-defined layer fits when the metrics feed your own product, read from ClickHouse, and must be scoped to one customer per request by the backend that already knows who is signed in. The embedded analytics guide covers that case.
Questions
Databricks metric views FAQ
What are Databricks metric views?
Metric views are Unity Catalog objects that define measures separately from the fields you group and filter by. You define a measure such as revenue once in YAML, and Databricks computes it at query time for whatever grouping the query asks for. A standard view fixes its aggregation when it is created.
Are Databricks metric views generally available?
Yes. Metric views became generally available on April 2, 2026, as part of Unity Catalog Business Semantics. They need Databricks Runtime 16.4 or later, with some features on newer runtimes; SQL warehouses always run the latest version. Relationships between metric views are in beta.
How do you query a metric view?
With SQL that wraps each measure in MEASURE(), for example SELECT `Customer country`, MEASURE(`Revenue`) FROM orders_metrics GROUP BY ALL. SELECT * is not supported, and a metric view cannot be joined directly with other tables; put the query in a CTE and join that.
Are Databricks metric views open source?
The core is. Databricks contributed metric views to Apache Spark, and Spark 4.2.0 ships them as CREATE VIEW ... WITH METRICS (SPARK-54119). Unity Catalog features such as materialization, Genie and Catalog Explorer authoring remain Databricks features.
Do row filters and column masks work with metric views?
They cannot be applied to the metric view itself, because Databricks does not allow row filters or masks on views. A metric view whose sources use row filters, column masks or ABAC cannot be materialized, and cannot be shared through OpenSharing.
Is Databricks part of Open Semantic Interchange?
Yes. Databricks joined in January 2026 and says it contributes to Apache Ossie, the name OSI took when it entered the Apache Incubator. The Ossie converters repository includes a Databricks metric views converter.
Guides
More on semantic layers
What is a semantic layer
What a semantic layer is, the five places one can live, and how dbt MetricFlow, Snowflake semantic views, Databricks metric views and OSI compare with a layer defined in code.
Read
dbt Semantic Layer and MetricFlow
Semantic models, metric types and the Semantic Layer APIs, compared with a semantic layer defined in code.
Read
Snowflake semantic views
CREATE SEMANTIC VIEW, the SEMANTIC_VIEW() query and Cortex Analyst, compared with a semantic layer defined in code.
Read
Open Semantic Interchange (OSI)
The vendor-neutral spec for exchanging semantic models: who is behind it, what the format covers and what it leaves out.
Read
ClickHouse semantic layer
Define datasets, measures and tenant keys for ClickHouse in TypeScript or Python.
Read
hypequery vs Cube
A code-first library compared with a standalone semantic layer service.
Read
Sources
Vendor pages used for this page, all read on November 10, 2026.
- Databricks docs
- docs.databricks.com/aws/en/uc-semantics/metric-views/
- docs.databricks.com/aws/en/uc-semantics/metric-views/create
- docs.databricks.com/aws/en/uc-semantics/metric-views/yaml-reference
- docs.databricks.com/aws/en/uc-semantics/metric-views/query
- docs.databricks.com/aws/en/uc-semantics/metric-views/basic-modeling
- docs.databricks.com/aws/en/uc-semantics/metric-views/materialization
- docs.databricks.com/aws/en/uc-semantics/metric-views/manage
- docs.databricks.com/aws/en/uc-semantics/metric-views/feature-availability
- docs.databricks.com/aws/en/uc-semantics/metric-views/bi-tools
- docs.databricks.com/aws/en/tables/row-and-column-filters
Next step
Define a semantic layer in your own codebase
hypequery datasets are TypeScript or Python files: dimensions, measures, joins and a tenant key, served to your API, React hooks and AI agents over MCP. Open source, for ClickHouse.