---
title: "What Is Unity Catalog's Semantic Layer?"
url: "https://atlan.com/know/ai-agent/semantic-layer/unity-catalog-semantic-layer/"
description: "Unity Catalog's semantic layer pairs metric views with business semantics in Databricks. See how it stacks up against dbt Semantic Layer and Cube on lock-in."
author: "Emily Winks"
author_role: "Data Governance Expert"
published: "2026-08-11"
updated: "2026-08-11T00:00:00.000Z"
---

---

Unity Catalog's semantic layer is Databricks' native answer to a familiar problem: every BI tool and every warehouse tends to invent its own version of what "revenue" means. Metric views are the mechanism Databricks built to stop that inside its own platform, and the engineering behind them is real, not a strawman. Atlan is one of 50-plus organizations, alongside Databricks, working through the Open Semantic Interchange (OSI) group, per [Datus's 2026 landscape report](https://datus.ai/blog/semantic-layer-tools-list-osi/), on the piece none of them have shipped yet: making metric definitions themselves portable, not just queryable.

That gap sits underneath a bigger shift already reshaping enterprise BI. Databricks isn't alone in building a [semantic layer](https://atlan.com/know/semantic-layer/) that only sees its own platform. [dbt Semantic Layer](https://atlan.com/dbt-semantic-layer/), Cube, Snowflake Semantic Views, and LookML are all doing the same thing in parallel, each one correct about its own metrics and blind to every other tool's version of the same metric. A [context layer](https://atlan.com/know/context-layer-vs-semantic-layer/) doesn't compete with any of them. It sits above the whole set, keeping "revenue" consistent whether the question comes from Genie inside Databricks or an agent working against dbt on the other side of the estate.

- Metric views: measures and dimensions defined once in Unity Catalog, materialized for query performance.
- Business semantics and agent metadata: synonyms, display names, and formatting that make a metric legible to Genie and other agents.
- Governance inheritance: metric views ride Unity Catalog's existing lineage and access controls, including attribute-based access control now in beta.
- Portability gap: no semantic layer product, Unity Catalog included, ships Open Semantic Interchange import or export yet.

---

## Quick facts

| Field | Content |
|---|---|
| What it is | A native semantic layer inside Databricks: metric views (measures and dimensions, materialized for performance) plus a business-semantics/agent-metadata layer that feeds SQL, BI tools, and Genie |
| Key benefit | Define a metric once inside Databricks and reuse it consistently across SQL, BI tools, APIs, and agents |
| Best for | Teams whose data estate already runs primarily on Databricks |
| Availability | Core metric view querying (SQL, BI, Genie) is broadly usable; specific modeling features like multi-fact relationships and materialization were still rolling out in public preview as of mid-2026 |
| Core components | Metric views (measures/dimensions), business semantics/agent metadata, governance inheritance (lineage, ABAC) |
| Not the same as | Unity Catalog Metrics, the richer modeling layer Databricks announced at Data + AI Summit 2026 |

---

## What is a metric view in Unity Catalog?

Underneath Unity Catalog's semantic layer sits the metric view, the mechanical unit that makes the rest of it work: a reusable SQL object that separates measures (the numbers you calculate, like revenue or churn) from dimensions (the fields you group and filter by, like region or product line). Standard views lock in a specific aggregation and grouping at creation time. A metric view defines the calculation once and lets any query group by whatever dimension it needs, then materializes the result so repeated queries don't re-scan the underlying tables.

Databricks describes the payoff as defining a KPI "once, then querying it consistently from SQL, BI tools, APIs, and agents." That's Databricks' own framing, and it holds up mechanically: according to [Microsoft Learn's Azure Databricks documentation](https://learn.microsoft.com/en-us/azure/databricks/uc-semantics/) (modified 2026-07-28), Unity Catalog semantics is built from exactly two components, metric views for the calculation logic and [agent metadata](https://atlan.com/know/ai-agent/data-for-ai/types-of-metadata-for-ai-agents/) for the synonyms and formatting that make a metric legible to AI tools. One source is promotional, one is purely technical, and they describe the same architecture.

One quick disambiguation: this is Databricks' Unity Catalog, unrelated to the Unity game engine, a mix-up common enough that it's worth stating plainly before going further.

Unity Catalog Metrics, the richer modeling layer Databricks announced at [Data + AI Summit 2026](https://atlan.com/know/ai-agent/databricks/databricks-data-ai-summit-2026-announcements/) (multi-fact relationships, level-of-detail calculations, parameterized metrics), builds on top of this same metric view mechanism. For how those definitions feed Databricks' own agent layer, see [Unity Catalog Metrics and the Genie Ontology](https://atlan.com/know/ai-agent/databricks/unity-catalog-metrics/).

A well-built metric view answers what a metric means inside Databricks. It says nothing about what happens the moment the same number needs to mean the same thing in Snowflake, dbt, or a BI tool that has never heard of Unity Catalog. That gap, not the engineering, is what the rest of this page is about.

---

## How does Unity Catalog's semantic layer work end to end?

The path from a raw table to a governed answer runs through three layers. First, a metric view defines the measure and its dimensions in SQL or YAML and materializes the result for performance. Second, a business-semantics layer sits above the metric view, adding the vocabulary that makes it usable by people and by agents, part of the broader shift toward [systems of semantics](https://atlan.com/know/ai-agent/data-for-ai/systems-of-semantics/) across enterprise data platforms. Third, the whole stack inherits Unity Catalog's existing [governance](https://atlan.com/know/ai-agent/data-for-ai/metadata-management-for-ai/) surface, so the same [lineage](https://atlan.com/know/ai-agent/data-for-ai/data-lineage-for-ai/) and access rules that apply to tables apply to the metrics built on top of them.

![Unity Catalog's semantic layer: metric view to governed answer, showing measures and dimensions feeding a materialized metric view, a business-semantics and agent-metadata layer above it, and governance inheritance wrapping both before reaching SQL, BI tools, and Genie agents](/img/unity-catalog-semantic-layer-1-metric-view-to-governed-answer.webp){width=1672 height=941}
Governed semantics flow from a materialized metric view to every interface, consistently. Source: Atlan.

### Business semantics and agent metadata

This layer adds synonyms, display names, and formatting rules: the difference between a column literally named `net_rev_usd_v3` and a metric an agent can correctly interpret as "net revenue in US dollars." Ali Ghodsi, CEO at Databricks, put the real work in plain terms: defining a semantic model is "simple YAML markup," but the actual effort is deciding "which tables, columns, joins, and metrics to include," work that must be tested rigorously and maintained long-term. That's an admission that the hard part of a [semantic layer for AI agents](https://atlan.com/know/ai-agent/semantic-layer-for-ai-agents/) was never the syntax.

### Governance inheritance: lineage, ABAC, and discovery

Metric views don't create a parallel governance system; they inherit the one Unity Catalog already has. Noel Yuhanna, VP and Principal Analyst at Forrester (2025-07-11): Unity Catalog now supports attribute-based access control in beta, alongside "full read/write governance support for Apache Iceberg tables, on par with Delta Lake." That same inheritance feeds the [Genie Ontology](https://atlan.com/know/ai-agent/databricks/genie-ontology/), a working example of what [ontology in AI](https://atlan.com/know/what-is-ontology-in-ai/) means in practice. How that ontology relates to a [cross-platform context layer](https://atlan.com/know/ai-agent/databricks/genie-ontology-and-atlan-context-layer/) is a separate question, since it's not something Genie was built to answer alone.

That inheritance is also exactly why this is one more place a metric definition can disagree with every other place it's defined. A metric view governed perfectly inside Databricks still can't know that dbt defines the same KPI three tables away with a different join. That's the fragmentation this category of tooling keeps recreating, one well-governed platform at a time.

  Get the Context Layer Ebook
  WTF is the context layer, actually? A plain-English breakdown of what it is, why metric views and semantic layers alone don't add up to one, and how to build it.
  Get the Context Layer Ebook

---

## Unity Catalog's semantic layer vs. dbt Semantic Layer and Cube

Unity Catalog's semantic layer is platform-native. dbt Semantic Layer and Cube are standalone. That distinction, not a feature checklist, is what actually matters when you're choosing between them.

According to [Datus's 2026 semantic layer landscape report](https://datus.ai/blog/semantic-layer-tools-list-osi/), the market splits into two camps: platform-native tools that live inside one warehouse (Unity Catalog Metric Views, Snowflake Semantic Views, LookML, Power BI) and standalone tools built to sit above any warehouse (dbt Semantic Layer, Cube, AtScale). Datus frames the practical consequence directly: a platform-native semantic layer is "the lowest-friction path when your estate already lives on one platform, and the highest-friction path if you add a second." That's not a knock on Unity Catalog. It's a description of what "native" always trades away.

The same structural split shows up one platform over, in [Snowflake Semantic Views](https://atlan.com/know/snowflake/snowflake-semantic-views/). [AtScale makes the identical argument](https://www.atscale.com/blog/snowflake-semantic-views-vs-universal-semantic-layer/) about Snowflake's version of this feature: it lets you "define metrics, dimensions, and relationships directly inside Snowflake, with no extra tooling required," exactly Unity Catalog Metric Views' pitch, wearing a different platform's name. Atlan's own comparison of the [best semantic layer tools](https://atlan.com/know/best-semantic-layer-tools/) for BI and AI agents covers where each fits in more depth.

| Aspect | Platform-native (Unity Catalog metric views) | Standalone (dbt Semantic Layer / Cube) |
|---|---|---|
| Where definitions live | Inside Databricks | Independent of any one warehouse |
| Multi-warehouse reach | Native to Databricks only | Works across Snowflake, BigQuery, Databricks, and others |
| Materialization and caching | Databricks-managed | Tool-managed, warehouse-agnostic |
| Version control | Unity Catalog object versioning | Git-native (dbt) or API-managed (Cube) |
| OSI import/export support | None shipped as of Datus's 2026 review | None shipped as of Datus's 2026 review; no product in the category has this yet |

The row that carries the most weight is the last one, and it's deliberately not a knock on Databricks: no product in this category, including the standalone tools that market themselves as platform-agnostic, ships Open Semantic Interchange import or export yet. Platform-native tools trade portability for simplicity today; standalone tools trade simplicity for portability once OSI ships, and it hasn't. Neither has solved the underlying problem: a metric defined in one tool still can't be authored once and owned everywhere, which the next section takes seriously instead of assuming away.

---

## When does Unity Catalog's semantic layer make sense, and when doesn't it?

Inside a single-platform Databricks estate, and for grounding Genie and other Databricks-native agents in a consistent metric, Unity Catalog's semantic layer earns its keep. It gets harder to justify the moment a second platform enters the picture.

Two use cases carry most of the value. Inside a Databricks-only estate, one metric view feeds every downstream dashboard the same number, which ends the common failure mode of two analysts pulling "revenue" from two slightly different queries. Because [Genie reads directly from Unity Catalog's business semantics layer](https://atlan.com/know/ai-agent/databricks/databricks-genie-context-requirements/), defining a metric there is also the most direct way to ground a Databricks-native agent, and the same governed definition can anchor [text-to-SQL for enterprise](https://atlan.com/know/ai-agent/data-for-ai/text-to-sql-for-enterprise/) queries against the same tables, rather than whatever a raw table's column names imply.

Both of these are genuinely strong reasons to use the feature. A [community discussion on r/PowerBI weighing Databricks metrics against Power BI's own semantic model](https://www.reddit.com/r/PowerBI/comments/1ozgnyi/semantic_layer_databricks_vs_power_bi/) shows teams working through exactly this tradeoff in live deployments, not in the abstract. The harder case is the one vendor documentation tends to skip past: what a team does once its BI tools, its warehouse, and its AI agents no longer all live on the same platform. That's the case the rest of this page is built around.

---

## Does Unity Catalog's semantic layer lock you into Databricks?

Databricks has a fair point here, worth stating plainly before complicating it: metric views are addressable via [MCP](https://atlan.com/know/ai-agent/databricks/add-context-to-databricks-genie-space/), SQL, and open APIs, so any tool outside Databricks can query one without buying into the rest of the platform. Databricks frames this as avoiding vendor lock-in, and on the narrow question of whether you can read a definition from outside Databricks, that's genuinely true.

Open access to query a definition is not the same question as portable authorship of that definition, and it's the distinction no vendor page states about itself. According to Datus's 2026 semantic layer landscape report, which tracked 15 semantic layer tools across both categories, no product, Unity Catalog included, ships native Open Semantic Interchange import or export as of the report date. You can read a Unity Catalog metric view from Snowflake. You cannot pick it up, with its full definition intact, and re-author it as a [Snowflake Semantic View](https://atlan.com/know/semantic-views-human-meaning-to-materialized-context/) or a dbt model without rebuilding it by hand, the same gap [data contracts for AI](https://atlan.com/know/ai-agent/data-for-ai/data-contracts-for-ai/) are meant to close, industry-wide.

Noel Yuhanna, VP and Principal Analyst at Forrester (2025-07-11): Unity Catalog Metrics is "a semantic layer for defining, storing, and governing business metrics," but "true unified governance would require seamless cross-platform interoperability, operational maturity, and tighter integration with other governance tools, which remain in early stages." An analyst credit and a caveat in the same sentence, and both halves are accurate.

Hold the line at that honest, narrower claim rather than manufacturing more anxiety than practitioners actually express. Daniel Beach, Senior Data Engineer at Rippleshot, writing in [Data Engineering Central](https://dataengineeringcentral.substack.com/p/databricks-semantic-layer-metric), calls the underlying concept "on the high moral ground," meaning explicit, YAML-defined business logic beats logic scattered across a dozen dashboards, and frames governance as "a bigger deal, the larger the organization." Practitioners aren't raising a lock-in alarm; they're describing a real tool with one unresolved edge. Some are already patching around it by hand: [Luca Martial's open-source ktx project](https://x.com/lucamrtl/status/2060005540952981611) pairs wiki-style context with semantic-layer relationships because, in his words, "valid SQL isn't always correct SQL," a community workaround for this exact gap, not evidence any vendor has closed it.

That edge is what the Open Semantic Interchange (OSI) working group, now incubating at the Apache Software Foundation as Apache Ossie, exists to close. Per [Datus's 2026 count](https://datus.ai/blog/semantic-layer-tools-list-osi/), Atlan is one of more than 50 organizations in that group, alongside Databricks, Snowflake, dbt Labs, Cube, and AtScale, working on making metric definitions themselves portable rather than merely queryable, and none of them, including Atlan, has shipped it yet. The honest answer to the lock-in question is narrower than "yes" or "no": you're not locked out of querying your metrics, but nobody, on any platform, can yet move the definition itself without rebuilding it.

  Find Your Context Gaps
  See exactly where your metric and business definitions diverge across Databricks, Snowflake, dbt, and your BI stack, before a mismatch reaches an agent.
  Find Your Context Gaps

---

## How to choose between a platform-native and a standalone semantic layer

The choice comes down to how homogeneous your estate is today, and how much migration risk you're willing to carry if that changes. Five criteria make the decision concrete instead of theoretical.

| Criterion | Why it matters | What to look for |
|---|---|---|
| Estate homogeneity | Platform-native tools are lowest-friction on one platform, highest-friction on two | Map every warehouse and BI tool your metrics must reach today |
| Multi-tool BI reach | A metric view only reaches what Databricks connects to | Confirm Power BI, Tableau, and Looker access, not just Databricks-native tools |
| Agent-governance requirements | Genie grounding is native; grounding a Snowflake-side or dbt-side agent is not | Decide which agents need the definition, not just which dashboards |
| Migration and lock-in tolerance | Definitions aren't portable yet on any platform, including this one | Treat this as a real cost, not a hypothetical, before committing |
| OSI-readiness roadmap | No product ships import or export today; that could change | Ask every vendor, not just Databricks, for their OSI timeline |

Ask every vendor the same OSI-readiness question, not just Databricks. The Open Semantic Interchange effort is genuinely industry-wide: Snowflake, dbt Labs, Cube, and AtScale are all working through the Apache Ossie incubation alongside Databricks, and as of Datus's 2026 review, none of them has shipped import or export yet. A vendor's OSI roadmap answer today is really a bet on how much rebuilding you're willing to sign up for later, on whichever platform you pick.

That question is already surfacing on its own, outside any vendor's marketing. An unprompted [thread on r/BusinessIntelligence](https://www.reddit.com/r/BusinessIntelligence/comments/1r9y5o0/why_arent_data_catalogs_used_as_semantic_layers/) asked why [data catalogs and semantic layers](https://atlan.com/know/ai-agent/semantic-layer/semantic-layer-vs-data-catalog/) still ship as separate tools at all, evidence the two are converging in practitioners' minds faster than any single platform has unified them. That convergence, not a feature comparison, is the real reason this decision is bigger than picking a semantic layer vendor. It's a bet on whether your metric definitions stay tied to one warehouse's export format or move somewhere they don't have to.

---

## How Atlan approaches semantic layers across Databricks, Snowflake, and dbt

A metric view is real, well-built engineering, and it solves the problem it was built to solve entirely inside Databricks. The moment "revenue" needs to mean the same thing in a Snowflake warehouse, a dbt model, and a Power BI dashboard at the same time, a platform-native semantic layer runs out of surface area. Not because it's poorly built, but because it was never designed to see past its own platform's edge.

Atlan doesn't replace Unity Catalog's semantic layer. It sits above it: the [context layer](https://atlan.com/know/what-is-the-enterprise-context-layer/) that unifies a metric view's definition, lineage, and ownership with the equivalent definitions living in dbt, Snowflake, or a BI tool, so Genie, a Snowflake-side agent, and a human analyst asking the same question get the same answer. That unification doesn't require OSI to exist first. Atlan hasn't shipped OSI import/export either, and it doesn't claim to; it connects to each platform's own APIs instead, the way its native Databricks connector crawls Unity Catalog schemas, tables, views, and the Model Registry, pulls lineage directly from Unity Catalog's system tables, and stitches it to lineage from every other connected system into one cross-platform [context graph](https://atlan.com/know/what-is-a-context-graph/). Bi-directional tag sync means governance policies set in Atlan propagate back to Unity Catalog for enforcement, not just for display.

Atlan is also a named participant in the Open Semantic Interchange working group, alongside Databricks, Snowflake, dbt Labs, Cube, and AtScale, working on the same interoperability gap this page describes rather than a separate one. A broader, non-metric-view-specific [review of Atlan's context layer deployments](https://atlan.com/know/context-layer-roi/) at more than 50 enterprises found over 209,000 hours of manual context work eliminated by moving to one shared definition layer instead of several disconnected ones; it's cited here as background on the approach, not as proof of this exact use case. The discipline behind connecting, rather than replacing, each platform's semantics is [context engineering](https://atlan.com/know/what-is-context-engineering/), laid out practically in [how to implement an enterprise context layer for AI](https://atlan.com/know/how-to-implement-enterprise-context-layer-for-ai/).

Unity Catalog's semantic layer is the floor. A shared definition layer built by connecting to every platform's native APIs, rather than waiting on a shared export format none of them have shipped yet, is the ceiling. It's the one thing a platform-native semantic layer, by definition, cannot build on its own.

  Check Your Readiness
  Is your data estate ready to hand AI agents a consistent metric definition, or does "revenue" still mean five different things across five tools?
  Check Your Readiness

Book a Demo





---

## FAQs about Unity Catalog's semantic layer

1. **Is Unity Catalog Metrics the same thing as Unity Catalog semantics?**
No. Unity Catalog semantics is the broader semantic layer, made up of metric views plus a business-semantics and agent-metadata layer. Unity Catalog Metrics is Databricks' name for the richer modeling features added to that same metric view mechanism at Data + AI Summit 2026, including multi-fact relationships, level-of-detail calculations, and parameterized metrics.

2. **What is a metric view in Databricks, and how is it different from a regular view?**
A metric view is a reusable SQL object that separates measures, the calculations, from dimensions, the fields you group and filter by, and materializes the result for performance. A regular view locks in a specific aggregation and grouping at creation time, so two people asking for revenue by region and revenue by quarter from the same regular view often need two different views. A metric view answers both from one definition.

3. **How is Unity Catalog's semantic layer different from dbt Semantic Layer or Cube?**
Unity Catalog's semantic layer is platform-native, meaning the definitions live inside Databricks. dbt Semantic Layer and Cube are standalone, meaning they sit above any warehouse and can serve the same metric definition to Databricks, Snowflake, BigQuery, and others at once. The platform-native approach is lower-friction on a single platform; the standalone approach costs more setup but reaches further.

4. **Does Unity Catalog's semantic layer work with Power BI and Tableau, or only Databricks-native tools?**
Metric views are queryable through SQL and open APIs, so BI tools that can connect to Databricks can query them directly, including Power BI and Tableau. Import support that brings existing Power BI and Tableau models into Databricks metrics is a separate, newer capability Databricks has rolled out on a beta basis, distinct from simply querying an existing metric view.

5. **Does using Unity Catalog's semantic layer lock you into Databricks?**
Not in the way lock-in usually gets used. Metric views are queryable from outside Databricks through MCP, SQL, and open APIs, so you are not locked out of reading your own definitions. What you cannot do yet, on any semantic layer platform, is export a metric's full definition and re-author it natively somewhere else, because no product has shipped Open Semantic Interchange support as of this writing.

6. **Is Unity Catalog's semantic layer generally available, or still in preview?**
Core metric view functionality, querying from SQL, BI tools, and Genie, is broadly usable today. Specific modeling capabilities layered on top, including multi-fact relationships and materialization, were still rolling out on a public preview basis as of mid-2026. Check Databricks' own Unity Catalog release notes for the current status of any specific capability before building against it.

7. **Is "Unity Catalog" the same as the Unity game engine?**
No. Databricks' Unity Catalog is a data governance and cataloging system for the Databricks platform. The Unity game engine is unrelated software from a different company, and the two share a name by coincidence rather than any connection.

---

## Sources

1. [Unity Catalog semantics, Microsoft Learn](https://learn.microsoft.com/en-us/azure/databricks/uc-semantics/)
2. [Beyond the Lakehouse: Databricks' Bold Play for the Business Persona, Forrester](https://www.forrester.com/blogs/beyond-the-lakehouse-databricks-bold-play-for-the-business-persona/)
3. [Semantic Layer Tools in 2026: Complete List + OSI (Apache Ossie), Datus](https://datus.ai/blog/semantic-layer-tools-list-osi/)
4. [Snowflake Semantic Views vs. Universal Semantic Layer, AtScale](https://www.atscale.com/blog/snowflake-semantic-views-vs-universal-semantic-layer/)
5. [Databricks Semantic Layer: Metric Views, Daniel Beach, Data Engineering Central](https://dataengineeringcentral.substack.com/p/databricks-semantic-layer-metric)
6. [Want an Intro to What Semantic Models Are, Ali Ghodsi, LinkedIn](https://www.linkedin.com/posts/alighodsi_want-an-intro-to-what-semantic-models-are-activity-7376086017654788096-5at7)
7. [Semantic Layer, Databricks vs Power BI, r/PowerBI](https://www.reddit.com/r/PowerBI/comments/1ozgnyi/semantic_layer_databricks_vs_power_bi/)
8. [Why Aren't Data Catalogs Used as Semantic Layers?, r/BusinessIntelligence](https://www.reddit.com/r/BusinessIntelligence/comments/1r9y5o0/why_arent_data_catalogs_used_as_semantic_layers/)
9. [ktx Open-Source Announcement, Luca Martial, X](https://x.com/lucamrtl/status/2060005540952981611)