You mirror Databricks Unity Catalog into Microsoft Fabric when you want Databricks to stay the system of record for engineering while Power BI, Teams, and Copilot consume the same data on the Microsoft side — with no copy, no export pipeline, and no second warehouse to keep in sync. Fabric mirrors the Unity Catalog metadata and reads the underlying Delta files in place through shortcuts, so one copy of data serves both platforms. This is a supported, generally available capability, not a workaround.

This guide is for the data leaders, BI and platform architects, and IT directors who already run Azure Databricks, have Microsoft 365 and Power BI on every desk, and are tired of treating "Databricks or Fabric" as a forced choice. It covers the two integration methods and when to use each, what the mirror actually does, the single most important thing to understand — that Unity Catalog permissions do not carry into Fabric — the table types that silently won't mirror, and how to run the governance seam so the business gets Direct Lake performance without quietly bypassing your security model.

Key takeaways

• Mirroring copies metadata, not data. Fabric syncs the Unity Catalog catalog structure and reads the Delta files in place through shortcuts, so there is no data movement and no duplicate storage, per Microsoft Learn.
• There are two integration methods with different release status. The Fabric-initiated "Mirrored Azure Databricks catalog" is generally available; the Databricks-initiated "Publish to Fabric" is in Public Preview, per Microsoft Learn.
• Unity Catalog permissions are not mirrored into Fabric. Microsoft states plainly that UC policies and permissions don't carry over, and you must re-establish access control using Fabric's permission model, per Microsoft Learn.
• Some table types silently won't mirror. Tables with row-level security or column masks, streaming tables, views, materialized views, Delta Sharing tables, and Lakehouse federated tables are not supported, per Microsoft Learn.
• The payoff is Power BI Direct Lake. A mirrored catalog can back a Direct Lake semantic model, so Power BI serves Databricks-maintained tables at import-like speed with no refresh pipeline and no gateway in the path, per the Microsoft Fabric blog.
• The fix for the governance gap is deliberate, not automatic. Mirror curated, security-trimmed gold schemas and enforce consumer-facing access once with OneLake security, which Direct Lake honors.

The short answer: what mirroring is and when to use it

Mirroring Azure Databricks Unity Catalog into Fabric creates a read-only, continuously synced view of your Databricks tables inside OneLake. Databricks remains the system of record — all writes go through Databricks — while Fabric becomes the consumption surface for T-SQL, Spark notebooks, and Power BI Direct Lake. Because both platforms store tables as open Delta, nothing is copied; Fabric reads the same files Databricks wrote.

The two integration methods compared

Mirrored Azure Databricks catalog (Fabric-initiated)

• Who starts it: A Fabric workspace admin selects New item, then Mirrored Azure Databricks catalog in the Fabric portal.
• What gets shared: Selected schemas and tables, with optional automatic sync of new ones.
• Release status: Generally available, per Microsoft Learn.

Publish a Unity Catalog catalog to Fabric (Databricks-initiated)

• Who starts it: An Azure Databricks catalog admin runs Catalog, then Share, then Publish to OneLake inside Databricks.
• What gets shared: The full catalog.
• Release status: Public Preview, per Microsoft Learn.

Both methods land the same result — Unity Catalog tables appearing in Fabric as a read-only mirrored catalog with no data movement. The practical difference is which team drives it. If the Fabric platform team owns the handshake and wants granular control over which schemas are exposed, use the GA Fabric-initiated method. If the Databricks team wants to publish an entire catalog from their own console, the Publish path exists but is still in preview, so weigh that for production.

How does the mirror actually work?

When you create a mirror, Fabric synchronizes the Unity Catalog metadata — schemas, tables, and ongoing changes — and accesses the underlying table data directly through shortcuts rather than importing it. Changes to the data may take anywhere from a few seconds to several minutes to appear on the Fabric side, per Microsoft Learn. By default, the option to automatically sync future catalog changes is enabled, so new schemas and tables show up and dropped ones disappear without a manual step.

Behind the mirror, Fabric creates a Mirrored Azure Databricks item and an autogenerated SQL analytics endpoint. From there you can query the data with T-SQL, process it in Spark notebooks, and — the headline capability — build a Power BI semantic model in Direct Lake mode against the mirrored item. That is the architecture The Adecco Group described in Microsoft's GA announcement: Databricks stays the engineering layer, and mirrored tables become "instantly usable for Power BI Direct Lake semantic models," per the Microsoft Fabric blog.

What you need before you start

• A Fabric workspace with capacity assigned, because metadata scans and refreshes consume Fabric capacity.
• External data access enabled on the Unity Catalog metastore, which is what lets Fabric read the registered tables at all.
• The EXTERNAL USE SCHEMA privilege on the Unity Catalog schema containing the tables Fabric will access, granted to the connecting user or service principal, per the Microsoft Learn tutorial.
• A Fabric runtime of at least Spark 3.4 and Delta 2.4, per the limitations documentation; the Publish path additionally requires Databricks serverless or Runtime 18.1 or above.
• Trusted workspace access configured when the underlying ADLS Gen2 storage sits behind a firewall, using the Fabric Workspace Identity.

Why don't my Unity Catalog permissions carry into Fabric?

This is the question that sinks dual-platform estates, and the answer is unambiguous. Unity Catalog policies and permissions are not mirrored into Fabric. Permissions set on catalogs, schemas, and tables inside Azure Databricks do not carry over to Fabric workspaces, and you must use Fabric's own permission model to control access to the mirrored objects, per Microsoft Learn.

It gets sharper. The credential used to create the mirror connection is the credential used for all data queries — the individual Power BI user's identity is not passed back to Unity Catalog for per-query evaluation. Databricks' own documentation is blunt that once a table is exposed in Fabric, "no Unity Catalog-governed access controls on that table apply to Fabric users," and that downstream Fabric users effectively bypass Unity Catalog governance — a situation that "can lead to potential violations of corporate information security policies," per Microsoft Learn. If you assume your Databricks row filters and column masks travel with the data, you will quietly over-expose it.

The mirror moves your tables in seconds, but it does not move your security model — and the gap between those two facts is where governance incidents are born.

At BabyBots, this governance seam is exactly the kind of boundary we design before a single report is built. We run fixed-fee Data and Decision Intelligence readiness assessments that map which schemas should be mirrored, where access control is re-established on the Fabric side, and how the handover stays audited — so the business gets its Direct Lake performance without inheriting a silent security hole. If you have both platforms and a board asking why BI still routes through a ticket queue, that is the session to book.

Which tables won't mirror, and why does it matter?

The mirror is selective in ways that surprise teams, because the tables it refuses are often the ones carrying your security. The following types are not supported, per Microsoft Learn.

• Tables with row-level security or column-mask policies, which is precisely why you cannot lean on Unity Catalog to filter data for Fabric consumers.
• Streaming tables and materialized views, which simply won't display in the selection list.
• Views, so any curation you expressed as a view in Databricks has to be materialized as a table to be mirrored.
• Delta Sharing tables and Lakehouse federated tables, which fall outside the supported set.
• Tables that don't use Delta Lake format, since the whole mechanism depends on the shared open Delta foundation.

The through-line is that your most governed Databricks objects are the ones the mirror leaves behind. That is not a bug to wait out — it is a signal to design the consumption layer deliberately rather than expecting the source controls to follow.

How do you run the governance seam correctly?

The pattern that works treats Unity Catalog and Fabric as two control planes with one audited handover point. Unity Catalog keeps governing production: who writes, what lineage says, and source-side permissions. Fabric governs consumption: workspace roles, model-level security, and sensitivity labels for the business audience. Two disciplines keep that honest.

Mirror curated schemas, not the whole estate

Expose published, security-trimmed gold schemas rather than bronze and silver working data. Because RLS and column-mask tables won't mirror anyway, the clean approach is to build per-audience gold schemas in Databricks that are already trimmed to what each audience may see, then mirror those. Your bronze chaos never earns a Direct Lake audience.

Enforce consumer security once, on the Fabric side

Rather than half-duplicating source rules into every semantic model from memory, enforce access once using OneLake security, which is generally available and supports table-, row-, and column-level security that Direct Lake honors. If your hard requirement is that Unity Catalog must remain the single security authority with the user's identity evaluated at query time, the honest answer is to stay on DirectQuery with single sign-on to Databricks instead of Direct Lake, as practitioners note in the Microsoft Fabric community. Choosing between Direct Lake performance and single-authority governance is a real trade-off — make it on purpose.

This is the same governed-coexistence thinking behind our guide on connecting Databricks to Copilot Studio: in both cases the data stays in the lakehouse and the Microsoft surface consumes it, and in both cases governance is a design decision, not a default.

What does mirroring cost to run?

There is no duplicate storage bill, because the data is never copied — the economics follow the architecture. What you do pay for is Fabric capacity: the mirror requires a running Fabric capacity to perform metadata scans and refreshes, per Microsoft Learn, and your Power BI and T-SQL consumption is billed as ordinary Fabric capacity usage. Compared with the alternative — scheduled export pipelines that run compute, age into a second copy, and drift — the mirror removes an entire class of cost and maintenance. The trade is predictable Fabric capacity for unpredictable pipeline sprawl.

Frequently asked questions

Is mirroring Databricks Unity Catalog into Fabric generally available?

Yes, for the Fabric-initiated method. The "Mirrored Azure Databricks catalog" that a Fabric workspace admin creates in the Fabric portal is generally available, per Microsoft Learn. The Databricks-initiated "Publish to Fabric" method, run from the Databricks Catalog Explorer, is still in Public Preview, so evaluate that one carefully before relying on it in production.

Does mirroring copy my Databricks data into Fabric?

No. Only the Unity Catalog metadata — the catalog structure — is mirrored, and Fabric reads the underlying Delta files in place through shortcuts. There is no data movement and no duplicate storage. Changes to the source data propagate to Fabric within seconds to a few minutes.

Are my Unity Catalog row-level security and column masks enforced in Fabric?

No, and this is the most important fact to internalize. Unity Catalog permissions and policies are not carried into Fabric, and tables that use row-level security or column masks don't mirror at all. You must re-establish consumer access control on the Fabric side, using OneLake security and curated, security-trimmed schemas, or stay on DirectQuery with SSO if Unity Catalog must remain the single query-time authority.

Can I build Power BI Direct Lake reports on mirrored Databricks tables?

Yes — that is the primary payoff. A mirrored Azure Databricks catalog can back a Power BI Direct Lake semantic model, giving import-like query speed with no scheduled refresh and no gateway in the path, while Databricks remains the system of record. You can also query the mirrored data with T-SQL through the autogenerated SQL analytics endpoint and process it in Spark notebooks.

What's the difference between mirroring and OneLake shortcuts to Databricks data?

Both avoid copying data, but a mirrored catalog tracks the whole Unity Catalog structure and keeps it in sync automatically, including new and dropped tables. Plain shortcuts point at specific folder paths and don't track catalog-level changes, so at tens or hundreds of tables the mirror is the difference between a managed pattern and a part-time job. The mirror is the first-class, no-copy integration for the "both platforms" estate.

Do I still need Databricks if I mirror everything into Fabric?

Yes. Mirroring makes Databricks tables readable in Fabric, but all writes still go through Databricks, which remains the system of record and the engineering and governance plane for your pipelines. The pattern is designed for coexistence — engineering keeps Databricks, the business keeps Power BI and Copilot — not migration off either platform.

Where this is heading

Microsoft and Databricks are steadily erasing the seam between their platforms: OneLake can now serve as native storage for Unity Catalog managed tables, and catalog federation lets each side read the other, all on the shared open Delta foundation. The direction of travel is clear — "Databricks or Fabric" is becoming "Databricks and Fabric, with clear boundaries," and the organizations that win are the ones that design those boundaries before they turn on the mirror. The capability is easy; the governance discipline is the differentiator.

Design your Databricks-to-Fabric architecture with BabyBots

If you run both Azure Databricks and Microsoft Fabric and want the Direct Lake performance without the silent governance gap, book a BabyBots Databricks-to-Fabric architecture assessment. In a single working session we map which gold schemas to mirror, where OneLake security re-establishes consumer access control, and how the handover between Unity Catalog and Fabric stays audited — so you leave with a governed design, not a list of open questions.

Sources

• Microsoft Learn — Mirroring Azure Databricks Unity Catalog
• Microsoft Learn — Microsoft Fabric with Azure Databricks (two integration methods)
• Microsoft Learn — Secure Fabric mirrored databases from Azure Databricks
• Microsoft Learn — Limitations in Fabric mirrored databases from Azure Databricks
• Microsoft Learn — Use Microsoft Fabric to read data registered in Unity Catalog
• Microsoft Learn — Publish a Unity Catalog catalog to Microsoft Fabric (Public Preview)
• Microsoft Learn — Tutorial: Configure Fabric mirror from Azure Databricks Unity Catalog
• Microsoft Fabric Blog — Mirroring Azure Databricks Unity Catalog to OneLake (GA)
• Microsoft Fabric Community — Databricks mirroring, Direct Lake, and RLS/masking