Unity Catalog vs OneLake Security: How Fabric and Databricks Governance Actually Compare

Most content on this topic is really about wiring the two platforms together, not about how their governance models actually differ. Both matter — here’s the real architectural comparison, plus exactly how far the 2026 integration between them goes, including a gap in it worth knowing about before you mirror anything sensitive.

Unity Catalog vs OneLake: What Each One Actually Governs

Unity Catalog is Databricks’ unified governance layer, and “unified” is doing real work in that sentence — it’s not marketing shorthand. Every governable thing in Databricks is modeled as a securable object inside one three-level namespace: catalog.schema.object, sitting under an account-level metastore. That namespace covers tables and views, but also volumes (non-tabular files), functions, ML models, and — as of the 2026 Data + AI Summit announcements — AI agents, tools, and MCP servers through the new Unity AI Gateway. More than 14,000 organizations now run their governance on Unity Catalog, per Databricks’ own 2026 figures.

This is the structural point worth sitting with: a Databricks admin reasons about governance in one system. A Fabric admin has to reason about three — who can open an item (workspace roles), who can see which rows and columns of Direct-Lake-backed data (OneLake security), and what’s labeled and tracked for compliance (Purview) — and understand how those three interact. We’ve documented exactly how that interaction can go wrong in our OneLake security and Direct Lake conflict guide, and it’s a direct consequence of governance being layered instead of unified.

Unity Catalog vs OneLake: What OneLake Security Governs

OneLake security lets you define row-level, column-level, and object-level access roles once, at the OneLake data layer, rather than redefining them inside every consuming semantic model. It’s a real and useful capability — but its scope is narrower than Unity Catalog’s. It applies to Direct Lake semantic models; a Warehouse query, a Lakehouse Spark job, or a SQL Database connection each go through their own separate access-control path instead of the same unified check. See our OneLake security guide for the full role model, and our Power BI row-level security guide for how the separate, DAX-based RLS layer inside a semantic model interacts with all of this.

The Permission Syntax Compared

Prose descriptions of “role-based access control” all start to sound the same. The actual difference shows up in how you grant access day to day.

Granting access in Unity Catalog

Unity Catalog permissions are plain ANSI SQL, granted directly on the three-level namespace:

GRANT SELECT ON TABLE main.sales.transactions TO `analytics_team`;
GRANT USE CATALOG ON CATALOG main TO `analytics_team`;
GRANT EXECUTE ON FUNCTION main.ml.fraud_score TO `risk_agents`;

Any object in the hierarchy — a catalog, a schema, a table, a function, a registered model — takes the same GRANT/REVOKE pattern. One mental model covers everything, which is precisely the point of a single governance plane.

Granting access in OneLake security

OneLake security roles are defined per Lakehouse through the Fabric portal (or REST API), scoped to that item rather than a shared namespace:

// OneLake data access role definition (Lakehouse-scoped)
{
  "name": "RegionalAnalysts",
  "members": { "entraGroups": ["sg-analytics-team"] },
  "decisionRules": [{
    "effect": "Permit",
    "permission": ["Read"],
    "members": { "fabricItemMembers": [{ "sourcePath": "Tables/sales/transactions" }] }
  }]
}

Notice the structural difference: a Unity Catalog grant references objects in a shared, queryable namespace that spans every workspace under the metastore. A OneLake security role is defined inside one specific Lakehouse and doesn’t automatically extend to a Warehouse or SQL Database holding related data — each needs its own access configuration, even within the same Fabric workspace.

Multi-Cloud and Cross-Platform Governance

Unity Catalog was built multi-cloud from the start — the same metastore model spans AWS, Azure, and GCP, and the open-sourced version (Apache 2.0, hosted under the LF AI & Data Foundation) supports the Apache Iceberg REST catalog API and Hive metastore API, making it usable by non-Databricks engines entirely. Federation extends this further: a Unity Catalog foreign catalog can expose external systems like Snowflake or a Fabric Warehouse SQL endpoint as a governed, queryable object inside Unity Catalog’s own namespace, without moving the data.

OneLake security has no equivalent open or multi-cloud story — it’s a Fabric-native capability, tied to Microsoft’s platform. OneLake Shortcuts extend Fabric’s reach into S3, ADLS Gen2, and Dataverse, but the security model governing what happens once that data is inside OneLake stays entirely within Fabric’s own three-layer stack. If cross-cloud governed access is a hard requirement, that’s a structural advantage for Unity Catalog, not just a maturity gap that closes with time.

Governing AI Agents: Unity AI Gateway vs Fabric’s Approach

Both platforms are racing to govern AI agents, not just data, and they’re taking different shaped approaches. Unity Catalog’s 2026 additions — Unity AI Gateway, Glossary, and Domains — extend the same governance plane that already covers tables and files to models, agents, tools, and MCP servers, plus a shared business-semantics layer so agents and humans work from the same defined concepts instead of guessing from raw column names.

Fabric’s answer is more distributed: Fabric IQ provides domain-aware grounding for agents, Data Activator and Fabric Data Agents handle specific agentic scenarios, and governance of what those agents can access still runs back through the same workspace-roles-plus-OneLake-security stack described above — there isn’t yet a single Fabric equivalent that unifies AI-asset governance the way Unity AI Gateway does for Databricks.

Coexistence in Practice: What Teams Running Both Actually Do

• Keep the system of record close to where data is created. Data landing first in Databricks stays governed in Unity Catalog; data landing first in Fabric stays governed by OneLake security. Mirroring moves the data, not the source of truth for who can see it.
• Treat mirrored data as needing its own access review, not inherited permissions — directly because of the enforcement gap described below.
• Use Unity Catalog’s federation for read access to Fabric Warehouse data when Databricks users need it, rather than physically duplicating tables.
• Pick one platform as the governance source of truth for shared business glossary terms (Unity Catalog Glossary or Purview’s business terms) rather than maintaining two competing definitions of what “active customer” means.

How Far the 2026 Integration Actually Goes

Microsoft and Databricks have been deepening interoperability rather than pretending the other platform doesn’t exist, and OneLake now supports Databricks’ Unity Catalog Open API standard — a real, meaningful adoption of an open governance protocol rather than a one-off connector. Here’s exactly where each direction of that integration stands:

The Security Gap Worth Knowing About Before You Mirror Anything Sensitive

This matters because the mirroring feature is explicitly marketed as delivering “enhanced data governance and security” through “the OneLake security framework” — and that framing is easy to misread as “Unity Catalog’s rules travel with the data.” They don’t, automatically. If a table is sensitive enough to be restricted in Unity Catalog, treat mirroring it into Fabric as a decision that needs its own, separate OneLake security configuration on the Fabric side — not an inheritance you can assume.

Which One Should You Actually Use?

Frequently asked questions

What is the main difference between Unity Catalog and OneLake security?

Unity Catalog is a single, account-level governance plane that covers every asset type in Databricks — tables, files, ML models, notebooks, dashboards, and AI agents — through one three-level namespace. OneLake security is one layer inside a broader, three-part Fabric governance stack (workspace roles, OneLake security, and Purview), and it applies specifically to Direct Lake semantic models rather than uniformly across every Fabric engine.

Can I connect Databricks Unity Catalog and Microsoft Fabric OneLake?

Yes, in one direction fully and the other partially. Mirrored Azure Databricks Unity Catalog in Fabric has been generally available since 2025 and lets Fabric read Unity Catalog-managed tables through OneLake with no data movement. Reading OneLake data from Databricks via Unity Catalog’s Open API standard reached public preview at FabCon 2026. Bidirectional write-back is on the roadmap but not yet available.

Does Unity Catalog security apply to mirrored data inside Fabric?

Not reliably. Independent testing has shown that security rules defined in Unity Catalog are not enforced once a table is mirrored into OneLake — the underlying Parquet files are still physically accessible directly through OneLake, bypassing the Unity Catalog permission the data owner configured. Treat this as an open gap rather than an assumption of inherited security when mirroring sensitive tables.

Can I register a Fabric Lakehouse as an external location in Unity Catalog?

No, not directly. OneLake’s raw storage endpoint is deliberately hidden behind the Fabric service layer rather than exposed as a standard dfs.core.windows.net endpoint, which is what Unity Catalog needs. Databricks has also blocked creating external locations pointing at OneLake storage items generally, with a narrow exception for the purpose-built Fabric Databricks Storage item.

Which is better for governance: Unity Catalog or OneLake security?

Unity Catalog is the more mature, unified governance system for estates spanning multiple engines, clouds, or asset types including ML models and AI agents. OneLake security is tightly integrated and simple to reason about for Fabric-only workloads centered on Direct Lake, but doesn’t extend the same way to Warehouse, SQL Database, or other non-Direct-Lake access paths.

Official references

• What is Unity Catalog? — Databricks documentation
• Expanding Support for OneLake in Unity Catalog — Databricks Blog
• Mirroring Azure Databricks Unity Catalog in Fabric — GA Announcement — Microsoft Fabric Blog

Related guides

• Microsoft Fabric vs Databricks — the full platform comparison this governance deep-dive extends
• OneLake Security in Microsoft Fabric — the full OneLake security role model
• OneLake Security and Direct Lake Conflict — how Fabric’s layered governance model can fail in practice
• Row-Level Security in Power BI — the semantic-model-level security layer, separate from OneLake security
• Data Mirroring in Microsoft Fabric — how Mirroring works more broadly, beyond the Databricks case

Verified against official Databricks and Microsoft Fabric documentation, the Databricks Data + AI Summit 2026 announcements, and Microsoft’s FabCon 2026 announcements, current as of July 2026. The Unity Catalog/OneLake integration is actively evolving on both sides — confirm current feature availability and security behavior before relying on this page for a production data-sharing decision. UIG Data Lab is an independent publication, not affiliated with or endorsed by Microsoft Corporation or Databricks, Inc.