In Short: One Copy of Data, Each Team's Best Platform
The most common realistic estate we meet is not Databricks or Fabric; it is both - engineering deep in Azure Databricks, the business living in Power BI, Teams and increasingly Copilot. Unity Catalog mirroring is the feature that makes that arrangement clean: point Fabric at a Databricks catalog, and its tables appear in OneLake - structure synchronised, data read in place, nothing copied - ready for every Fabric engine and the Microsoft AI layer on top.
Databricks remains the system of record. Fabric becomes the consumption surface. The seam between them is one configured item instead of a fleet of exports.
How It Actually Works
The mirror leans on the platforms' shared foundation: both store tables as Delta. Fabric synchronises the Unity Catalog metadata - schemas, tables, changes over time - and reads the table data directly from the underlying storage via shortcut mechanics. New tables engineering publishes show up; dropped ones disappear; nobody runs a copy job.
From the Fabric side, the mirrored catalog behaves like read-scenario OneLake data: T-SQL via the SQL endpoint, Spark in notebooks, and - the headline - Direct Lake semantic models, meaning Power BI serves Databricks-maintained tables at import-like speed with no refresh pipeline and no gateway in the path.
Why This Beats the Alternatives It Replaces
- Versus export pipelines: nothing to schedule, nothing to drift, no second copy ageing quietly in a warehouse
- Versus plain shortcuts: the mirror tracks the whole catalog, not folder paths - at tens or hundreds of tables, automatic sync is the difference between a pattern and a part-time job
- Versus DirectQuery to Databricks SQL: Direct Lake reads files, not a warehouse endpoint, so BI crowds stop being a sizing problem on the Databricks side (that pattern remains right when its trade-offs are)
The economics follow the architecture: no duplicate storage, no export compute, and BI consumption billed as ordinary Fabric capacity.
The Governance Seam, Made Explicit
Dual-platform estates fail on ambiguity, so this pattern's best property is that it forces clarity. Unity Catalog keeps governing production: who writes, what lineage says, source-side permissions. Fabric governs consumption: workspace access, model RLS, labels for the business audience. The mirror is the audited handover point.
Two disciplines keep it honest. Mirror curated schemas - gold, published - rather than the whole estate: bronze chaos does not deserve a Direct Lake audience. And decide consumer-facing security once, on the Fabric side, rather than half-duplicating source rules into models by memory - the readiness checklist applies to mirrored domains exactly as to native ones, especially before Copilot meets them.
For organisations that have been treating Databricks versus Fabric as a forced choice: this is the feature that retires the question for most workloads. Engineering keeps its platform, the business keeps its experience, and the data - one copy, open format - serves both.
Sources and Further Reading
Frequently asked
A mirrored item in Fabric that surfaces the tables of an Azure Databricks Unity Catalog in OneLake. Fabric reads the Delta data via shortcuts under the hood - the data is not copied - and keeps the catalog structure in sync, so new and changed tables appear without manual work.
No. Because both platforms speak Delta, the mirror is metadata synchronisation plus direct reads of the same underlying files. That is what makes the pattern cheap and trustworthy: one copy, two platforms.
Everything it does with native OneLake data within read scenarios: SQL endpoint queries, notebooks, and crucially Power BI semantic models in Direct Lake mode - plus the AI layer, since Copilot and Fabric data agents can ground on the mirrored tables.
Databricks and Unity Catalog remain the system of record and govern engineering: writes, lineage, source permissions. Fabric governs consumption: workspace access, semantic model security, labels. The mirror is the explicit seam - configure each side deliberately rather than duplicating rules by hand.
Shortcuts point at storage paths one folder at a time; the mirror tracks the catalog. If engineering adds tables weekly, the mirror keeps Fabric current automatically and preserves catalog structure, which at estate scale is the difference between a pattern and a chore.
