What a Databricks Metric View is
A Metric View is a Unity Catalog object that lets you define data mappings, measures, and dimensions centrally in SQL, and govern them directly in Unity Catalog. Definitions then flow consistently to the tools that consume them, AI/BI Dashboards and Genie, so a metric means the same thing everywhere. Databricks announced general availability and open-sourcing of Unity Catalog business semantics, including Metric Views, in 2026.
A metric view is defined against a source (a table, another metric view, or a SQL query), with fields (dimensions) and measures. It can also declare materializations, display names, formats, and synonyms so AI and BI tools discover the right measure.
How you query one
Measures are aggregate expressions that do not carry a pre-set grain. To use a measure in a query you reference it with the MEASURE() function, and the metric view 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 regardless of who queries it or how they slice it.
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 | Databricks plus 15+ 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 |
Where Metric Views stop
- Databricks-scoped. Metric Views live in Unity Catalog and describe lakehouse data. Cross-warehouse questions need the data in Databricks.
- Definition, not execution. A Metric View standardizes what a metric means. Turning an arbitrary question into governed, deterministic SQL is the consumer's job, and Genie, the main AI consumer, is Databricks-bounded and LLM-driven. See Databricks Genie alternatives.
- Authored and maintained. Someone defines and updates the views as models change.
This is a real, welcome step for governed metrics on Databricks, and open-sourcing the spec is a genuine plus. The point is scope: a Metric View is a governed metric definition in the lakehouse, not a cross-warehouse, compile-time execution layer.
Fix the Context, Not the Model. Metric Views are this principle in Unity Catalog: define the meaning, govern it centrally. The next step is proving and governing the query at compile time, across every warehouse, not just Databricks.
What a semantic execution layer adds
Colrows can build on the same governed meaning and go further: it compiles intent through a typed semantic graph into deterministic, dialect-perfect SQL across Databricks and 15+ other engines, proves join paths, and enforces governance before execution so filtered rows are never read. For teams standardizing on Databricks today but planning for a multi-warehouse, agent-driven future, Metric Views and a semantic execution layer are complementary: the governed definition, and the compiler that governs it everywhere. Snowflake's equivalent object is covered in Snowflake Semantic Views explained.
Frequently asked questions
What is a Databricks Metric View?
A Unity Catalog object defining measures and dimensions centrally, governed in Unity Catalog and consumed by AI/BI Dashboards and Genie. Business semantics went GA and open-source in 2026.
How do you query one?
Reference measures with the MEASURE() function against the view's fields (dimensions); window measures handle cumulative and semi-additive aggregations.
What are the limits?
Databricks and Unity Catalog scoped, an authored definition rather than a compile-time cross-warehouse execution engine, with governance enforced at query time.
