For most of the last decade, the honest answer to "should we standardize on Databricks or on the Microsoft data platform?" was: pick one and live with the seams. Teams that ran Azure Databricks for engineering and Microsoft Fabric (or Synapse before it) for BI ended up maintaining two copies of the same tables, two governance models, and a nightly export job that nobody wanted to own. The duplication was not a technical accident. It was the price of two platforms disagreeing about where the bytes lived and who was allowed to read them.
That premise is now obsolete. Over the past year Microsoft and Databricks have quietly converged on a shared physical foundation — OneLake — and on a shared governance contract anchored in Unity Catalog. As of mid-2026 the interoperability is bi-directional and, in the important cases, zero-copy. If you architect for it deliberately, you can keep a single copy of a Delta table, write to it from Databricks, query it from a Fabric Warehouse or Power BI, and enforce one set of row- and column-level policies across both. If you architect for it accidentally, you can just as easily rebuild the old two-copy mess with newer logos on it. This piece is about how to land on the right side of that line.
The three doors between the platforms
The first thing to get straight is that "Fabric–Databricks integration" is not one feature. It is at least three distinct mechanisms with different data-flow semantics, and choosing the wrong one is the most common architecture mistake I see.
Mirrored Azure Databricks Catalog was the opening move, and it is now generally available. Fabric reads Unity Catalog tables that physically live in ADLS Gen2 by materializing OneLake shortcuts — virtual links, not copies — to the underlying Delta files. There is no data movement and no replication; Fabric polls Unity Catalog metadata and reflects DDL changes (new tables, drops, schema edits) at the next sync interval, with a manual refresh available when you cannot wait. Crucially, the mirrored tables are read-only in Fabric because the source of truth stays in Databricks. This is the right door when Databricks owns the write path and Fabric is a consumption surface.
OneLake external locations for Unity Catalog (Beta as of June 2026) inverts the storage question. Instead of Databricks writing to ADLS Gen2 and Fabric shortcutting to it, you create a Unity Catalog external location that maps to a OneLake path, and from that point every UC asset type — managed tables, views, materialized views, streaming tables — lands directly in OneLake. OneLake becomes the primary storage destination rather than a mirror of storage that lives elsewhere. The tables remain fully managed Unity Catalog tables, so predictive optimization, liquid clustering, and UC governance all still apply. The difference is that the single physical copy now sits inside the Fabric-native lake from the moment it is written.
Publish to Fabric (Preview) is the connective tissue between the two. It is a Databricks-native workflow, launched from Catalog Explorer, that creates the mirrored catalog item in one or more Fabric workspaces regardless of whether the underlying tables are backed by OneLake or ADLS Gen2. It exists so that engineers never have to leave the Databricks console to make their tables visible to Fabric analysts, and so the same catalog can be published to several Fabric workspaces independently.
Read those three together and the design space becomes clear. Reading Databricks data from Fabric is solved by mirroring. Reading OneLake data from Databricks is solved by OneLake catalog federation, which is now GA and lets Azure Databricks query OneLake directly. Writing Databricks-managed tables straight into the Fabric lake is solved by OneLake external locations. The old requirement to copy data to cross the platform boundary has been removed in every direction that matters.
The architecture decision: who owns the write path?
The single most consequential choice is where your managed tables physically live, and it should be driven by who owns writes, not by which vendor your leadership likes this quarter.
If Databricks is your engineering platform of record — Lakeflow pipelines, DLT, Spark structured streaming, MLflow-tracked feature tables — then Unity Catalog must remain the source of truth, and you have two viable storage layouts. Keep managed tables in ADLS Gen2 and expose them through Mirrored Databricks Catalog, or move the storage into OneLake via external locations and use Publish to Fabric. The second option is the stronger long-term bet when Fabric is a first-class consumption tier, because it eliminates even the shortcut indirection: Power BI Direct Lake, Fabric SQL analytics endpoints, and notebooks all read the same physical Delta files that Databricks wrote, with no second hop. The trade-off is maturity. OneLake external locations are Beta, and I would not put a regulated production workload's only copy on a Beta storage path without a fallback and a very clear conversation with whoever owns your recovery objectives.
If Fabric owns significant write workloads — Dataflows Gen2, Fabric Warehouse T-SQL, Real-Time Intelligence eventhouses landing to the lake — then OneLake is already your center of gravity, and the interesting move is letting Databricks federate into it rather than the reverse. OneLake catalog federation going GA is what makes this credible: Spark and ML workloads reach into OneLake-resident data under native governance without you standing up a parallel copy in a Databricks-managed bucket.
What you should stop doing is treating this as a data-movement problem. If your first instinct is still to schedule a copy job between the platforms, you are paying for storage twice, doubling your reconciliation surface, and — the part that actually gets people fired — forking your governance.
Governance is the real integration, not the pipes
The zero-copy story is easy to demo and easy to oversell. Sharing bytes is the boring half of the problem. The half that determines whether this survives an audit is whether a single access policy follows the data across engines. Here the 2026 developments are more important than the storage plumbing.
OneLake security has been extended to cover mirrored Azure Databricks data, and the mapping is concrete rather than aspirational. You use Automatic Identity Management in Databricks to sync a Microsoft Entra ID group and grant it Unity Catalog privileges — say USE, BROWSE, and SELECT on a catalog. You mirror that catalog into Fabric, then create a OneLake data access role over the mirrored shortcuts and add the same Entra group. The result is that a user who can select from the NorthWind catalog in Databricks sees exactly that data, and only that data, when they query it through a Fabric lakehouse, notebook, or semantic model. Table-level security is in preview across all engines, with row- and column-level security in early access. The governance model is no longer "replicate the grants by hand and hope they stay in sync" — it is one identity, defined once, enforced on both sides.
This is also where the Databricks-side announcements from Data + AI Summit 2026 start to matter for a Microsoft-heavy shop. Catalog Federation now extends Unity Catalog governance across accounts, regions, and clouds with a zero-copy federated path, and Automatic Identity Management reached GA for Entra. For AI workloads specifically, the new Unity AI Gateway puts agent and model traffic behind a single governed entry point with spend caps, PII guardrails, and routing — which means the same catalog that governs your Delta tables can govern the retrieval and model calls sitting on top of them. If you are building RAG or agentic systems against enterprise data, having the vector retrieval path (Lakebase Search now lives inside Postgres under Unity Catalog permissions) and the analytics path answer to the same policy engine is the difference between a governable system and a shadow one.
What to actually do with this
For architects standing up a greenfield estate, my default recommendation in 2026 is: make Unity Catalog the governance authority, make OneLake the storage substrate, and use Publish to Fabric as the seam. Keep Databricks as the write and transformation engine, let Fabric be the serving and BI tier reading the same physical tables, and define access once through Entra groups mapped into both UC and OneLake security. Treat OneLake external locations as production-bound but validate on non-critical domains first while it is Beta.
For teams with an existing two-copy pipeline, do not rip everything out at once. Pick one high-friction dataset — usually the one that already causes reconciliation tickets between the engineering and BI teams — mirror it instead of copying it, wire up the shared Entra group, and prove the governance holds under a real access review. The zero-copy savings are nice; the governance simplification is what will actually convince your security org to let you retire the export jobs.
The strategic read is bigger than any single feature. Microsoft and Databricks have decided that fighting over where your bytes live is a worse business than agreeing on it, and the format war that Delta, Iceberg, and the various catalogs spent years on is settling into interoperability rather than a winner. For data engineers, that is unambiguously good news: fewer copies, one governance contract, and the freedom to use the best engine for each job without paying a duplication tax to cross the boundary. The teams that win the next few years will be the ones who stop architecting around the seam and start architecting as if it is already gone — because, increasingly, it is.
