Microsoft has made OneLake external-location support for Azure Databricks Unity Catalog generally available in Microsoft Fabric, with OneLake Security enabled by default for Azure Databricks Storage items. On the Azure Databricks side, the feature remains in public preview. The change lets supported Unity Catalog-managed data be stored directly in OneLake while Databricks continues to provide compute and Unity Catalog management.
Data teams that run Microsoft Fabric and Azure Databricks in the same architecture often have to deal with duplicated data, synchronisation pipelines and separate access models. This integration gives them a shared physical storage location for supported workloads, rather than a separate copy for each platform. It does not make Fabric and Databricks a single governance plane.
What changed
A Unity Catalog external location can now point to an Azure Databricks Storage item in OneLake. A catalog or schema can then use that external location as managed storage. Supported Azure Databricks workloads write their underlying data directly into OneLake.
Teams can continue to create and manage supported managed tables, volumes, views, materialised views and streaming tables through Azure Databricks and Unity Catalog. The Fabric side provides the capacity-backed workspace and Azure Databricks Storage item. OneLake provides the storage location.
The update builds on the earlier beta for OneLake external-location support in Unity Catalog. The main production change is the default security posture for Azure Databricks Storage items. OneLake Security is on by default, and no user receives access when the item is created.
Access is reserved for the Databricks identity
Fabric workspace roles do not grant access to data in an Azure Databricks Storage item. Administrator, Member, Contributor and Viewer roles in the Fabric workspace cannot be used to read or write the stored data. Microsoft says only the Azure Databricks identity should access the storage item directly.
That identity can be the managed identity of an Access Connector for Azure Databricks, or a service principal. It must have the Viewer role on the Fabric workspace and be the only member of a ReadWrite OneLake security role on the Azure Databricks Storage item. Users, groups and other service principals should not be added to that storage role, because direct access would bypass Unity Catalog governance.
The intended model is that Unity Catalog remains the place where access to the data is granted, reviewed and revoked. Fabric users read the data through a mirrored Azure Databricks catalog item, not through the storage item itself. The mirrored item shows selected Unity Catalog catalogs, schemas and tables in a Fabric workspace without copying the data.
Requirements and setup
The Azure Databricks workspace must be enabled for Unity Catalog. Compute must be serverless or a classic compute resource running Databricks Runtime 18.1 or later. The user configuring the integration needs the required Unity Catalog privileges to create storage credentials and external locations.
On the Fabric side, the workspace must have capacity assigned. A Fabric administrator must allow users to create Azure Databricks Storage items in the tenant settings. The workspace must also have OneLake user-delegated SAS token authentication enabled in its OneLake settings.
The setup has four main parts. Platform teams create the Fabric workspace and Azure Databricks Storage item, configure the approved identity, create a Unity Catalog storage credential, and then create the OneLake external location in Azure Databricks. The external location uses an ID-based ABFSS path in the OneLake namespace, not display names.
Microsoft’s documentation gives the path format as abfss://workspace-id@onelake.dfs.fabric.microsoft.com/databricks-storage-id/Files/. Name-based paths are rejected when the external location is created. After the external location is in place, a catalog or schema can use it as managed storage.
Reading the data in Fabric
Fabric users do not work against the Azure Databricks Storage item directly. They use a mirrored Azure Databricks catalog item. Analysts and engineers can query the mirrored item through the SQL analytics endpoint, notebooks and Power BI reports.
The mirrored catalog item can be created from either side. Azure Databricks users can publish a catalog to Fabric, choosing the Fabric workspace where the mirrored item should appear. Fabric users can also create a Mirrored Azure Databricks catalog item by connecting to the Azure Databricks workspace and selecting the catalog, schemas or tables to include.
This distinction matters for governance. The storage item is reserved for the Azure Databricks identity. Fabric readers use the mirrored catalog item, where access remains tied to the published Unity Catalog objects rather than the raw storage path.
Current limitations
The preview status on the Azure Databricks side is one constraint. Microsoft has also documented feature limitations that affect Fabric access and sharing scenarios.
Fabric Spark cannot read tables with catalog commits through a mirrored Azure Databricks catalog. Catalog commits are enabled by default for Unity Catalog managed tables in new catalogs and schemas through automatic upgrades. The documented workaround is to turn off catalog commits on tables that Fabric Spark workloads need to read, using ALTER TABLE table-name DROP FEATURE 'catalogManaged', but that also disables features that depend on catalog commits for that table.
Databricks-to-Open sharing is not supported for managed tables whose storage is on OneLake. That sharing route gives recipients pre-signed URLs to table data files, and OneLake storage paths do not support pre-signed URLs. Fabric also does not recognise the FILE type, so FILE columns are omitted from mirrored Azure Databricks catalogs even when other columns are mirrored.
What platform teams need to decide
The integration is most relevant where Fabric and Azure Databricks already coexist and teams want to reduce storage duplication. It does not remove the need to decide which platform owns compute, catalog management and user-facing access. Microsoft’s design keeps Databricks compute and Unity Catalog management on the Databricks side, with Fabric supplying the workspace and OneLake storage item.
The security model is also deliberately narrow. Direct storage access should be limited to the Azure Databricks identity. If teams add users or groups to the OneLake security role for the storage item, they create a second access route outside Unity Catalog governance.
The decision to place Unity Catalog-managed data in OneLake while keeping direct access limited to the Databricks identity is the kind of storage, governance and analytics boundary ECS's Data topic covers, alongside Microsoft Fabric, Power BI, SQL Server and Dataverse. Sessions and workshops give attendees room to compare Fabric architecture choices with practitioner experience from mixed Fabric and Azure Databricks environments. Bring the catalogue, storage and access-control questions that are difficult to settle from documentation alone.
This article was written by the ECS editorial team with the assistance of Amal Agent, run.events' AI assistant, which supported the research, drafting and proofreading.