Unity Catalog Metric Views, now in Power BI: one unified, governed semantic layer for all your reporting and AI

Organizations want a single, trusted definition of their business semantics. Revenue, margin, and active customers should mean the same thing in every report, notebook, and AI application. When they don't, business users and AI agents read the same data differently and reach different answers. Finance and sales show different revenue numbers, teams lose trust in their reports, and decisions get made on the wrong numbers. Unity Catalog metric views, part of Unity Catalog semantics, solve this by enabling customers to define business KPIs once in Databricks, in an open, governed semantic layer that sits on top of the lakehouse.

At the same time, many of these organizations rely on Power BI as the front end for their business users. Often, organizations have thousands of PowerBI workspaces each with its own Semantic Models, creating a governance and unification nightmare. Furthermore, when each team builds its own metrics and relationships in Power BI, the same logic lives in many places. Reports drift apart, and every definition change means updating each copy.

Customers have told us they want both: Databricks as their unified, open semantic layer, and Power BI as their front end. With Publish to Power BI, they can now have both. Every Power BI report uses the same governed UC metric views as AI/BI dashboards and Genie, so teams work from consistent numbers. Business users can build self-serve reports and explore metrics across any dimension without waiting on a data team to model data or write DAX. Data teams maintain one definition in Databricks instead of many copies across systems. Publish on demand from Catalog Explorer, or add a Power BI task to a Lakeflow Job to keep metric views and semantic models in sync in production.

Model once in Databricks, use it in Power BI

With Publish to Power BI or a Power BI task, you can connect Unity Catalog metric views to a Power BI semantic model. Each metric view becomes a table in the model. The metric view’s dimensions (aka Fields) become columns and its measures become DAX measures.

Power BI queries the metric view itself (as if it was a table). The metric view stays the source of truth, and joins defined in the metric view run in Databricks. Joined dimensions, such as campaign channel or region, show up in Power BI as ordinary columns, so you don't have to rebuild table relationships in Power BI.

For example, a marketing team needs to track campaign performance and decide where to shift budget. They define a campaign_performance metric view in Unity Catalog with dimensions such as channel and region and measures such as total spend, total revenue, and return on ad spend (ROAS). When the team publishes the metric view, those dimensions and measures arrive in Power BI like this:

A marketing analyst can then build a Power BI report that compares ROAS by channel and region, and see the same numbers the team gets in AI/BI dashboards and Genie. If the team later changes what counts as total_revenue they update the metric view once, a Power BI task in their pipeline republishes it, and every Power BI report picks up the new definition.

Fast by design

Because Power BI queries the metric view, it will soon be able to benefit from metric view materialization too. Metric view materialization is a performance optimization that pre-computes results without changing how metrics are calculated. When Power BI sends a query, Databricks will serve it from a matching materialization for faster results. If no materialization matches, the query runs against the metric view as usual. Either way, the metric definitions, DAX measures, and results are identical.

Additionally, with Lakehouse//RT + DirectQuery, Power BI reports get real-time performance, directly on your governed lakehouse data. Lakehouse//RT runs on your managed Delta tables, so there's no separate serving system to copy data into or manage. It also enforces the same Unity Catalog row filters, column masks, and ABAC policies, so reports get faster without giving up governance.

Governed and always in sync

With DirectQuery, every query honors Unity Catalog access controls and security policies, and lineage stays connected to the metrics your teams already use in AI/BI dashboards, Genie, and Databricks Lakehouse.

When a metric view changes, we make it easy to keep Power BI up to date. Using Power BI tasks in Lakeflow Jobs, you can publish your metric views to the target semantic model as a step in your data pipeline, on a schedule or right after upstream tables refresh. Updated measures, new measures, and new dimensions flow into Power BI automatically, so reports stay aligned with the metrics layer without manual rework.

What’s supported

Publish to Power BI covers the metric definitions most teams use day to day:

• Data modeling: Define your data model directly in metric views, including joins and relationships, dimensions, measures, and other semantic metadata, and let Databricks handle the computation automatically without manually duplicating logic in Power BI.
• Measures: Standard aggregations (SUM, COUNT, AVG, MIN, MAX, MEDIAN, STDDEV, VARIANCE), distinct counts, ratios, filtered measures, and measures composed from other measures.
• Window measures: Current, offset, and trailing window measures.
• Metadata: Descriptions and display formats including currency, decimal and percentage settings carry over to Power BI field properties.
• Storage modes: DirectQuery (the default) for live queries against Lakehouse/RT or Databricks SQL, and Import mode for loading data into Power BI.
• Publishing mechanisms: Use Publish to Power BI in Catalog Explorer to publish metric views on demand in a few clicks. Use Power BI tasks in Lakeflow Jobs to automate publishing as part of your data pipeline, so metric views and semantic models stay in sync in production.

Get started

Publish to Power BI is available in Private Preview (documentation). Work with your account team to test out the preview.

Once enabled, you can publish in three easy steps:

1. Prepare the metric view(s): Add any measure inputs as dimensions and make sure every field is named.
2. Publish: In Catalog Explorer, click Publish > Publish to Power BI, sign in with your Power BI credentials, and choose a target workspace. When you're ready for production, add a Power BI task to a Lakeflow Job to automate publishing, ensuring your Power BI semantic model stays in sync with your metric view.
3. Validate in Power BI: Open the semantic model and confirm that the metric view appears as a table, dimensions appear as columns, and measures appear as DAX measures.

Together, these capabilities make Databricks the home of your semantics. Define your metrics once in Databricks, keep Power BI models in sync using Power BI tasks, and use the same governed definitions everywhere, including the Power BI reports business users already rely on. Every team and use case works from one open, governed platform.