A data leader needs one answer first. Does a Metric View turn any business question into governed, deterministic SQL across the whole data estate? It does one part of that job well. It also stops at the Databricks boundary. The table below sets the scope before the detail.
Metric View (definition) vs semantic execution layer
| Dimension | Databricks Metric View | Semantic execution layer (Colrows) |
|---|---|---|
| What it is | A definition object: governed measures and dimensions | A compile-time engine that resolves, proves, and governs queries |
| Reach | Databricks and Unity Catalog only | Databricks plus 16+ engines, one graph |
| Governance | Unity Catalog, enforced at query time | Compile-time RBAC + ABAC + row/column predicates |
| Determinism | Consistent metrics; consuming AI (Genie) is nondeterministic | Deterministic by construction |
| Maintenance | Authored definitions (SQL/YAML) | Autonomous, continuously maintained graph |
Read it this way. A Metric View is a governed definition. A semantic execution layer is a compiler that proves and governs the query itself. The two solve different problems. For the wider multi-engine picture, see the semantic layer buyer's guide 2026.
What a Databricks Metric View is
A Metric View is a Unity Catalog object. You define data mappings, measures, and dimensions once, and govern them in Unity Catalog. The definition then flows to every tool that consumes it, so a metric means the same thing everywhere.
A metric view is defined against a source. The source can be a table, another metric view, or a SQL query. It carries fields (dimensions) and measures. It can also declare materializations, display names, formats, and synonyms so AI and BI tools find the right measure.
Take net revenue as an example. You define the measure once, with its filters and its aggregation rule. You attach dimensions such as region, product, and quarter. Every dashboard, notebook, and Genie space then reads that one definition. Two teams asking for last-quarter revenue by region get the same number. The metric no longer depends on who wrote the SQL.
General availability and open source
Unity Catalog Business Semantics, including Metric Views, reached general availability on 2 April 2026. Databricks introduced the feature in DBR 16.4. Older runtimes cannot author or read Metric Views.
Databricks also open-sourced the core. The engine ships in Apache Spark under SPARK-54119. The catalog side ships in Unity Catalog OSS v0.5. Snowflake shipped its own schema-level object about a month earlier, with standard SQL querying generally available on 2 March 2026. The native semantic layer war is now live and citable. See Snowflake Semantic Views explained for the other side.
Both native objects share one trait. Each one lives inside its own platform. A Snowflake Semantic View cannot read Databricks, and a Metric View cannot read Snowflake. So the moment your data sits in more than one place, a single-vendor object leaves a gap. The dbt Semantic Layer is the main standalone option that spans warehouses today, and that fact keeps coming up as the tiebreaker. A semantic execution layer answers the same multi-engine need at the point of execution, not just definition.
How you query one
Measures are aggregate expressions that do not carry a pre-set grain. You reference a measure with the MEASURE() function. The metric view then resolves the correct aggregation at your chosen dimension level. Window measures support cumulative and semi-additive calculations. The result is one governed definition that returns consistent numbers, whoever asks and however they slice it. This is context defined once, not query logic rewritten for each dashboard. For the theory behind that idea, see what is a semantic compiler.
How Metric Views are consumed
You author measures and dimensions in YAML. One definition then serves many surfaces. Dashboards, notebooks, and Genie read it inside Databricks. External BI tools read it too, including Power BI, Tableau, and Sigma. Excel and Sheets add-ins reach the same measures. A metric returns the same number in every one of these places.
Governance rides along with the definition. A Metric View inherits Unity Catalog controls, so row and column rules apply wherever the measure is read. Access stays consistent from the notebook to the Power BI report. You set the policy once, in one place, and every consumer respects it.
Genie is the natural-language layer over your governed data, and Metric Views feed Genie spaces. A Genie space accepts up to 30 tables. Databricks recommends five or fewer for accuracy. Curate the space, and Genie answers stay close to the governed definition. Push past the recommended size, and answer quality falls. For that trade-off, see Databricks Genie alternatives and Colrows vs Databricks Genie. For the cross-cloud version of the same question, see Cortex Analyst vs Genie.
Where Metric Views break
- Nesting is unsupported. You reference a measure with
MEASURE(). You cannot wrap that call in another aggregate. A pattern likeSUM(MEASURE(...))does not compile. - Databricks-only. A Metric View lives in Unity Catalog and describes lakehouse data. You cannot query it from Snowflake or BigQuery. Cross-warehouse questions need the data inside Databricks first.
- Unity Catalog is required. Without Unity Catalog, there are no Metric Views.
- DBR 16.4 minimum. The feature arrived in DBR 16.4, so older runtimes are out.
There is also a maintenance cost. A Metric View is an authored artifact. Someone writes the YAML, and someone updates it when the source tables change. As columns move or business rules shift, the definitions drift unless a person keeps them current. The work is manual, and it grows with the number of views.
None of this makes Metric Views weak. They govern lakehouse metrics well, and the open-source move is a genuine plus. The point is scope. A Metric View is a governed definition inside one platform. It is not a cross-warehouse, compile-time execution engine. If your estate spans both clouds, read the Snowflake and Databricks semantic layer question.
Fix the Context, Not the Model. A well-governed semantic layer that understands business context creates more reliable AI-driven analytics than fine-tuning the model itself. Metric Views apply that principle inside Unity Catalog. A semantic execution layer applies it across every engine.
What a semantic execution layer adds
A Databricks-only object cannot span a multi-warehouse estate. That is the line a semantic execution layer crosses. Colrows builds on the same governed meaning and goes one step further. It compiles intent through a typed semantic graph into deterministic, dialect-perfect SQL. It runs that SQL across Databricks and 16+ other engines from one graph. It proves join paths before execution. It enforces governance at compile time, so filtered rows are never read. The runtime is one line: intent → context resolution → constrained planning → governed execution.
For a team standardizing on Databricks today but planning for a multi-warehouse, agent-driven future, the two are complementary. Keep the Metric View as the governed definition. Add the compiler that governs and executes it everywhere. To weigh the options for yourself, see the semantic layer for Databricks deep-dive or compare Colrows with the native tools.
The definition layer is only half the decision. For the assistant that sits on top of it, see conversational BI tools scored on governance and determinism, score candidates with the semantic layer evaluation checklist, and check the enterprise text-to-SQL accuracy benchmark before trusting any vendor's published accuracy number.
For the products that read Metric Views, and the renames around them, see Databricks AI and BI tools compared.
Frequently asked questions
What are Databricks metric views?
Databricks Metric Views are Unity Catalog objects. They define measures and dimensions once, in YAML, and govern them centrally. Dashboards, notebooks, and Genie then consume the same definition. Business semantics reached general availability on 2 April 2026 and were open-sourced the same year.
How do metric views differ from standard views?
A standard view stores a query and returns rows at a fixed grain. A Metric View stores measures without a pre-set grain. It resolves the aggregation at query time, at the dimension level you choose. That gives one consistent number across every tool.
What is the MEASURE() function?
MEASURE() is how you reference a measure in a query. The Metric View resolves the correct aggregation at your chosen dimensions. You cannot nest it inside another aggregate. A pattern like SUM(MEASURE(...)) is unsupported.
Metric views vs Snowflake semantic views?
Both define governed measures and dimensions for AI and BI. Metric Views are Databricks-only and need Unity Catalog. Snowflake Semantic Views are Snowflake-only. Neither queries the other platform. See Snowflake Semantic Views explained for that side.
Can Databricks metric views span other warehouses?
No. A Metric View lives in Unity Catalog and describes lakehouse data only. You cannot query it from Snowflake or BigQuery. Spanning many engines is the job of a semantic execution layer, which compiles one governed graph into every dialect.
