Mirroring Azure Databricks Unity Catalog into Microsoft Fabric is a zero-copy, generally available integration that exposes your lakehouse tables in OneLake without moving or duplicating a single byte — but the one thing it does not carry across is your Unity Catalog security. Grants, row-level filters, and column masks you set in Databricks do not follow the data into Fabric, so you have to re-establish access control using Fabric's own model or risk exposing data to anyone who can reach the Fabric workspace. That gap is the single most important thing to understand before you mirror anything sensitive.

This guide is written for the data architects, platform owners, and security leads who already run Azure Databricks, are standardizing reporting on Microsoft Fabric and Power BI, and need the two platforms to share one governed copy of data without opening a compliance hole. It covers how the integration actually works, the two ways to set it up, exactly where Unity Catalog governance stops at the Fabric boundary, the current state of bi-directional OneLake access in 2026, and the control pattern that keeps the whole estate defensible.

Key takeaways

• Mirroring is zero-copy and generally available: Fabric mirrors only the Unity Catalog structure and reads the underlying Delta data through OneLake shortcuts, so there is no data movement and changes propagate in seconds to minutes.
• Unity Catalog permissions do not transfer: grants on catalogs, schemas, and tables in Databricks are not mirrored to Fabric — Microsoft's documentation is explicit that you must reconfigure access control in Fabric's permission model.
• Governed access can be bypassed: Fabric queries run under the credential that created the connection, not the user asking the question, so downstream Fabric users can see data Unity Catalog would have blocked.
• Protected tables are excluded, not enforced: tables that use row-level filters or column masks — along with views, materialized views, and streaming tables — are not supported by the read integration.
• Interoperability now runs both ways: Databricks reading OneLake data is generally available, and native storage of Databricks managed tables in OneLake is in preview heading to general availability with OneLake security.
• The fix is Fabric-side governance by design: OneLake security, workspace roles, and Microsoft Purview must be configured deliberately in Fabric, because the integration will not inherit your lakehouse controls for you.

The short answer: does Unity Catalog governance survive mirroring?

No — not automatically. Mirroring brings the data across but leaves the policy behind, and treating the mirrored tables as if they were still governed by Unity Catalog is the mistake that turns a zero-copy convenience into a data-exposure incident.

• What transfers: the catalog, schema, and table structure, plus the live Delta data through shortcuts — read-only and always current.
• What does not transfer: Unity Catalog grants, row-level security, column masks, and attribute-based access rules.
• Who the data runs as: the identity that configured the connection, which means downstream Fabric users inherit that access rather than their own.
• What you must do: rebuild access control in Fabric using workspace roles and OneLake security before exposing anything sensitive.

How does mirroring Azure Databricks Unity Catalog into Fabric work?

Mirroring is a zero-ETL, SaaS integration that creates a read-only, continuously synced view of your Databricks tables inside OneLake. When you mirror a catalog, Fabric copies only the catalog structure and reaches the underlying Delta files through shortcuts, so there is no data movement or replication, according to Microsoft's mirroring documentation. Changes to the source data appear in Fabric after a short propagation window that can run from a few seconds to several minutes.

Behind the scenes, Fabric provisions a Mirrored Azure Databricks item and an autogenerated SQL analytics endpoint on a Lakehouse. From there you can query the data with read-only T-SQL, build Power BI reports in Direct Lake mode for near-import performance without a separate refresh, and process the tables in notebooks and Spark. Metadata auto-sync is on by default, so new schemas and tables added in Databricks flow into Fabric — and deletions flow through too.

What mirroring quietly leaves out

The integration is deliberately scoped, and the exclusions matter for governance. Materialized views and streaming tables are not displayed, external tables that are not in Delta format are skipped, and — most importantly — tables that use row-level filters or column masks are not supported at all. In practice, the very tables you have most carefully protected in Unity Catalog are the ones the read integration will refuse to surface, which pushes teams toward exposing the unprotected base tables instead.

Mirror or publish? The two integration paths compared

Azure Databricks and Fabric connect in two directions, and the right one depends on which team drives the integration. Both produce the same end state — a read-only mirrored catalog in Fabric with no data movement — but they differ in who initiates and how much is shared, per Microsoft's integration-method documentation.

Mirroring versus publishing at a glance

Mirrored Azure Databricks catalog (Fabric-initiated)

• Who starts it: a Fabric workspace admin, via New > Mirrored Azure Databricks catalog.
• What is shared: selected schemas and tables, with optional auto-sync of new ones.
• Release status: generally available.
• Best for: teams that want Fabric to pull a curated subset and keep it current.

Publish to OneLake (Databricks-initiated)

• Who starts it: an Azure Databricks catalog admin, via Catalog > Share > Publish to OneLake.
• What is shared: the full catalog.
• Release status: public preview.
• Best for: data teams that want to push an entire governed catalog to Fabric from the Databricks side.

Whichever path you choose, writes always go back through Azure Databricks — the mirrored tables in Fabric are read-only by design.

Where exactly does Unity Catalog governance stop?

This is the part that gets missed in the demo and discovered in the audit. Unity Catalog policies and permissions are not mirrored into Fabric: permissions set on catalogs, schemas, and tables in Databricks do not carry over, and you cannot reuse them in Fabric, as Microsoft states plainly in its security guidance for mirrored databases. You have to use Fabric's permission model to set access control on the mirrored objects.

It gets sharper. The credential used to create the connection is the credential used for all data queries, and Fabric performs authorization with short-lived Unity Catalog credentials tied to the identity that configured the connection — not the identity running the query. Microsoft's own Databricks documentation puts it in blunt terms: Fabric engines do not apply Unity Catalog governance and security policies to Fabric users, so no Unity Catalog access controls on a mirrored table apply to those users, and this can lead to potential violations of corporate information security policies. Downstream Fabric users do not even need the EXTERNAL USE SCHEMA privilege the configuring user needed, which means they effectively bypass the Unity Catalog gate entirely.

The data crosses the boundary intact; the policy that protected it does not, and nothing in the default setup warns you.

The prerequisites reinforce where the trust actually sits. You must enable external data access on the Unity Catalog metastore and hold the EXTERNAL USE SCHEMA privilege on the schemas Fabric will read, and Unity Catalog row-level security, column masks, and attribute-based access control are not enforced at the storage layer — so any path that reaches the storage directly ignores them. The honest reading is that mirroring hands governance responsibility to Fabric, and if you have not rebuilt the controls there, the data is as open as the Fabric workspace is.

If your organization is weighing this seam as part of a larger Databricks-plus-Microsoft estate, this is exactly the kind of boundary BabyBots maps in a fixed-fee Databricks–Fabric governance review — we trace every path your lakehouse data can take into OneLake, Power BI, and Copilot, and flag where a Unity Catalog control silently stops applying before it becomes an audit finding.

Can Azure Databricks read and write OneLake now?

Yes — the seam runs both ways in 2026, which changes the architecture conversation from "which platform owns the data" to "which single copy do both platforms share." Reading OneLake data from Azure Databricks through Unity Catalog is generally available, and native storage of Databricks managed Delta tables directly in OneLake moved into preview and is on the roadmap for general availability with OneLake security, per Microsoft's OneLake data-foundation update. Because there is a single copy, a change made in one environment is reflected in the other with no pipeline in between.

The write path carries its own governance caveat worth reading before you enable it. When you connect Azure Databricks to a OneLake external location, any principal holding a non-viewer role — Member, Contributor, or Administrator — in the Fabric workspace can read, write, and delete the data regardless of whether Unity Catalog granted them access, according to Microsoft's external-location documentation. Microsoft's own mitigation is to treat that Fabric workspace as privileged and restricted: keep it dedicated, and keep the list of Member, Contributor, and Administrator principals short.

This bi-directional foundation is also what makes the conversational layer light up — once your lakehouse data lives in OneLake, it is reachable by Power BI, Fabric data agents, and Microsoft Copilot. We cover that surface in depth in our guide on Databricks Genie versus Microsoft Copilot for conversational analytics, and the hands-on wiring in connecting Databricks to Copilot Studio.

How do you keep governance intact across Databricks and Fabric?

The integration will not inherit your controls, so you design them on the Fabric side on purpose. The sequence below is the one that holds up in a real estate rather than a sandbox.

1. Decide where authoritative security lives. Keep Unity Catalog as the system of record for lakehouse access, and treat Fabric as a second enforcement plane you must configure — not a mirror of the first.
2. Re-establish access control in Fabric. Use Fabric workspace roles plus OneLake security to apply row-, column-, and object-level rules to the mirrored data, since OneLake security now enforces those controls on every query.
3. Contain the connection identity. Because every query runs as the connection's credential, scope that identity tightly and treat the workspace holding mirrored or external-location items as privileged and restricted.
4. Avoid surfacing unprotected base tables. Tables with row filters or masks will not mirror, so do not expose their unmasked source tables as a workaround — recreate equivalent protection in Fabric instead.
5. Extend classification and lineage with Purview. Apply sensitivity labels and track lineage in Microsoft Purview so the data carries compliance context into Fabric, where Unity Catalog lineage does not follow.
6. Audit the seam continuously. Review who holds non-viewer roles in the relevant Fabric workspaces, and reconcile Fabric access against Unity Catalog intent on a schedule, not once at go-live.

Frequently asked questions

Is mirroring Azure Databricks into OneLake zero-copy?

Yes. Mirroring replicates only the Unity Catalog structure and reaches the underlying Delta data through OneLake shortcuts, so there is no data movement or duplication. Data stays in its original storage, and Fabric reads it in place, with changes propagating in seconds to minutes.

Do my Unity Catalog permissions apply in Fabric after mirroring?

No. Grants, row-level filters, and column masks set in Unity Catalog are not mirrored and cannot be reused in Fabric. You must configure access control in Fabric using workspace roles and OneLake security, or the mirrored data is governed only by Fabric's defaults.

What is the difference between mirroring and publishing to OneLake?

Mirroring is initiated by a Fabric workspace admin and shares selected schemas and tables with optional auto-sync; it is generally available. Publishing is initiated by an Azure Databricks catalog admin and shares the full catalog; it is in public preview. Both yield a read-only mirrored catalog in Fabric with no data movement.

Which Databricks objects will not mirror into Fabric?

Views, materialized views, and streaming tables are not supported, non-Delta external tables are excluded, and tables protected by row-level filters or column masks are not supported by the read integration. Unity Catalog lineage also does not follow operations performed in Fabric.

Can Databricks now write data to OneLake?

Reading OneLake from Azure Databricks is generally available, and native storage of Databricks managed tables in OneLake is in preview heading to general availability with OneLake security. The write path requires care: any non-viewer principal in the target Fabric workspace can read, write, or delete the data regardless of Unity Catalog grants, so that workspace should be dedicated and tightly restricted.

Does mirroring add Fabric cost?

Yes. Using Fabric to read Unity Catalog data requires a running Fabric capacity to perform metadata scans and refreshes, which consumes capacity units in addition to your Databricks spend. Model the shared-capacity impact before you mirror broadly, especially where Direct Lake semantic models drive heavy Power BI traffic.

Where this is heading

Microsoft and Databricks are converging on a single, open copy of data in OneLake that both platforms read and write natively, and the 2026 releases — generally available mirroring, generally available OneLake reads from Databricks, and native Databricks storage in OneLake moving toward general availability — make the dual-platform estate a mainstream architecture rather than a workaround. The storage silo is effectively dissolving. The governance seam is not, and it is where the real design work now concentrates. As the two platforms share more data more directly, the organizations that win are the ones that treat the boundary between Unity Catalog and OneLake security as a first-class control surface, not an implementation detail they discover after the first audit.

Map your Databricks–Fabric governance boundary with BabyBots

If you are bridging Azure Databricks and Microsoft Fabric, book a BabyBots Databricks–Fabric governance assessment — in a single working session we map every path your lakehouse data takes into OneLake, Power BI, and Copilot, pinpoint where Unity Catalog controls stop applying, and hand you a Fabric-side enforcement plan that keeps the estate defensible. Start at babybots.ai and we will scope it to your tenant.

Sources

• Microsoft Learn — Mirroring Azure Databricks Unity Catalog
• Microsoft Learn — Secure Fabric mirrored databases from Azure Databricks
• Microsoft Learn — Tutorial: Configure a Fabric mirror from Azure Databricks Unity Catalog
• Microsoft Learn — Use Microsoft Fabric to read data registered in Unity Catalog
• Microsoft Learn — Microsoft Fabric with Azure Databricks: choose an integration method
• Microsoft Learn — Connect Azure Databricks to a OneLake external location
• Microsoft Learn — Enable OneLake catalog federation
• Microsoft Fabric Community — Unlocking Microsoft OneLake as the data foundation for Azure Databricks customers
• Databricks Blog — Expanding support for OneLake in Unity Catalog (November 2025)
• Databricks Blog — What's New in Azure Databricks at FabCon 2026