1. Compare policy scope, not the number of governance products

Unity Catalog’s unified data/AI governance does not mean that ordinary notebook workspace permissions vanish. Fabric’s layered model does not mean OneLake security applies only to Power BI. Evaluate the policies needed by your estate rather than declaring a winner from a diagram.

2. What OneLake security actually controls

Microsoft describes two planes: control-plane workspace/item permissions govern what someone can do to an item; data-plane OneLake roles govern which data an applicable user can see or change. Roles can grant supported Read/ReadWrite access and granular table/column/row restrictions.

These controls are not Direct-Lake-only. Microsoft documents supported Fabric compute paths and requirements for reading secured OneLake data. SQL analytics endpoint access mode and the effective identity are important; some engines/paths require configuration and have limitations.

Inspect overlapping grants and the DefaultReader role where relevant. Item Read is not automatically equivalent to data access through every engine. SQL RLS/permissions apply to the SQL path; Power BI model RLS applies through the model. Do not assume one of these automatically secures every direct read.

3. What Unity Catalog does—and what remains outside a simple GRANT

Unity Catalog provides a data/AI object model, access control, discovery, lineage and auditing. Tables, views, volumes, functions and registered models are examples of governed objects. Policies, compute support, catalog bindings and required parent privileges still matter.

A table SELECT grant is not the whole design. Check required catalog/schema privileges, supported row filters/masks/ABAC, managed versus external assets, storage credentials and the actual compute mode. An account spanning several clouds does not automatically make one metastore or one permission configuration govern every region/provider identically.

Workspace objects also have ACLs. Notebook/job/dashboard sharing, the job’s execution identity and the underlying data privileges answer different questions. Do not grant broad storage access and assume a user who bypasses the intended engine will still receive its query-layer filters.

Use documented SQL/API examples for the exact object and current API version. This guide deliberately avoids a fabricated universal OneLake JSON role payload or a SQL namespace that claims every workspace resource is a table-like securable.

4. Fabric mirroring: the policy boundary you must preserve

For Azure Databricks Unity Catalog mirroring, Microsoft documents that the catalog structure is mirrored and underlying data is accessed through shortcuts. It is not necessarily a copy of the source rows into a second storage location, and propagation need not be immediate.

Microsoft also explicitly states that Unity Catalog permissions/policies are not mirrored into Fabric and must be configured separately. The connection credential is used for data queries. A direct-storage route does not automatically enforce source row filters, column masks or ABAC.

This is a documented integration boundary, not evidence that every user can read every mirrored table or that an independently reproduced vulnerability was found. Effective Fabric/storage permissions determine what the new path exposes. Do not label unexecuted documentation research as hands-on testing.

1. Approve a narrow set of supported tables and classify the protected columns/rows.
2. Record connection and storage identities, network path and authorized Fabric readers.
3. Implement equivalent approved restrictions on the Fabric paths actually used.
4. Test permitted and denied users through SQL, Spark/OneLake and Power BI as applicable.
5. Recheck after source schema/policy changes and connection rotation.

Do not assume read interoperability enables bidirectional writes or every external-location pattern. Validate the specific direction, connector, table feature and supported identity against current integration documentation.

5. SQL endpoint modes and Direct Lake are separate choices

Both modes require control-plane access to the item. Switching modes can temporarily make SQL endpoints across the workspace unavailable and cancel running/queued queries; plan it as a production change, not a universal shortcut-403 repair. Check the documented producer/consumer identity requirements too.

For Power BI, identify Direct Lake on SQL versus Direct Lake on OneLake. The SQL variant supports documented fallback conditions; the OneLake variant does not support DirectQuery fallback. SQL permissions, OneLake roles and semantic-model RLS/OLS are not interchangeable labels.

Do not disable OneLake security because an older guide says it always blocks Direct Lake. Use the current security integration matrix and the affected user’s actual error. Likewise, a successful report does not prove a direct SQL or Spark reader is appropriately restricted.

6. A governance acceptance checklist for teams using both

• List every supported access path, effective identity and policy decision point.
• Separate management permissions, data grants and source-engine policies.
• Verify one allowed and one denied case per protected row/column/table rule, using owner-approved test records.
• Review broad/elevated roles, shared connection identities and direct storage grants.
• Confirm expected data is visible; an empty result alone is not proof of correct RLS.
• Capture audit evidence, policy owners, change/revocation propagation and recovery procedures.
• Document what does not transfer across platforms, including permission grants and unsupported object/table features.

Choose the system that fits the authoritative data/AI estate, then govern each additional consumption path explicitly. Do not move sensitive data or broaden access just to make the architecture appear more unified.

Common questions

Official references and review scope

Checked against the following official vendor documentation on 2026-10-30. This is an independent comparison, not a vendor endorsement or a benchmark report. Recommendations are conditional on workload requirements. No customer deployment, savings result or performance benchmark is claimed; validate the design and current feature availability in your environment.

• OneLake control/data planes and supported scope
• OneLake role and data-access control model
• OneLake security for SQL endpoint modes
• Unity Catalog object model
• Databricks workspace ACLs
• Azure Databricks mirroring architecture
• Documented security boundary for mirrored Databricks data
• Direct Lake variants and security support

Take the next practical step

Practice Fabric interview scenarios