{"id":19941,"date":"2026-10-06T15:14:24","date_gmt":"2026-10-06T15:14:24","guid":{"rendered":"https:\/\/www.exam-labs.com\/blog\/?p=19941"},"modified":"2026-10-06T15:14:24","modified_gmt":"2026-10-06T15:14:24","slug":"databricks-data-engineer-professional-delta-sharing-governance","status":"publish","type":"post","link":"https:\/\/www.exam-labs.com\/blog\/databricks-data-engineer-professional-delta-sharing-governance","title":{"rendered":"Databricks Data Engineer Professional: Delta Sharing Governance"},"content":{"rendered":"

Delta Sharing has been renamed OpenSharing<\/strong> in current Databricks product documentation following the 2026 release of the open-source OpenSharing standard. The approved title uses the familiar older name, but new governance design should use current OpenSharing terminology and APIs. The service is built on Unity Catalog securables\u2014shares, recipients, and providers\u2014to expose governed data and AI assets across Databricks accounts, clouds, or non-Databricks recipients without copying data into the recipient’s ownership first.<\/p>\n

Within Databricks Data Engineering<\/a>, sharing governance is about deciding exactly which assets leave the producer’s normal trust boundary, who can receive them, how authentication works, and which policies still apply after sharing.<\/p>\n

The existing Unity Catalog governance<\/a> article provides the broader privilege and accountability model.<\/p>\n

Shares are securable collections of assets<\/h3>\n

A Unity Catalog share groups tables, views, volumes, notebooks, models, and other supported assets for distribution to external recipients.<\/p>\n

Only approved assets should enter a share; do not expose a broad schema merely because one consumer needs two tables.<\/p>\n

Maintain share descriptions, owner, business purpose, data classification, and intended recipients so the object functions as a governed product rather than an ad hoc export list.<\/p>\n

Recipients represent external consumers<\/h3>\n

The provider creates a recipient object that represents the external organization or consumer identity.<\/p>\n

Access to shared data is granted by associating the recipient with a share rather than by granting end users directly on the provider’s tables.<\/p>\n

Keep one recipient per meaningful external security boundary so revocation, IP restrictions, token rotation, and audit remain understandable.<\/p>\n

Databricks-to-Databricks sharing is the preferred native path<\/h3>\n

When both parties use Unity Catalog-enabled Databricks, Databricks-to-Databricks OpenSharing avoids long-lived bearer credentials and integrates with recipient\/provider objects in both metastores.<\/p>\n

Current Databricks-to-Databricks sharing can support richer assets and audit\/usage tracking than open-client scenarios.<\/p>\n

Use it when available instead of distributing static credentials merely because open sharing looks simpler during a proof of concept.<\/p>\n

Databricks-to-Open can use OIDC federation or bearer tokens<\/h3>\n

Non-Databricks recipients can use the open sharing protocol. OIDC federation is preferable where supported because it avoids long-lived static bearer credentials.<\/p>\n

Bearer-token recipients still exist, but current policy caps new token lifetime at one year.<\/p>\n

Tokens issued before December 8, 2025 with longer\/no expiry are scheduled to expire by December 8, 2026, so legacy integrations need rotation planning now.<\/p>\n

Bearer tokens require explicit rotation and compromise handling<\/h3>\n

Providers can rotate a recipient token and choose a short overlap window while the recipient moves to the new credential.<\/p>\n

If a token is suspected compromised, Databricks recommends expiring it immediately.<\/p>\n

Store activation links\/credential files through a secure delivery mechanism and never treat the recipient credential as a normal artifact in email threads or source control.<\/p>\n

Provider privileges should be delegated narrowly<\/h3>\n

Current Unity Catalog privileges such as CREATE SHARE, USE SHARE, SET SHARE PERMISSION, CREATE RECIPIENT, and USE RECIPIENT let organizations delegate sharing administration without making every data-product owner a metastore admin.<\/p>\n

Separate authority to create a share, add assets, manage recipients, and grant share access according to the organization’s data-governance workflow.<\/p>\n

A data engineer should not automatically be able to create a new external recipient for sensitive assets.<\/p>\n

ABAC row filters and masks require special sharing design<\/h3>\n

Current OpenSharing guidance supports sharing tables protected by ABAC policies when the share owner is correctly exempted for provider-side access.<\/p>\n

For recipient-side views that need filtering\/masking, one recommended pattern is to share base tables and apply local ABAC policies to the read-only shared tables before users access local views.<\/p>\n

Unity Catalog Row Filters<\/a> and Unity Catalog Column Masks<\/a> cover those policy controls.<\/p>\n

Cloud-token access can expose table history, including deleted data<\/h3>\n

For eligible full-history Delta table shares, OpenSharing can issue temporary path-scoped cloud credentials so recipients read files directly for better performance.<\/p>\n

Databricks warns that access to the table root and Delta log can expose commit history and deleted data that has not yet been vacuumed.<\/p>\n

Do not share WITH HISTORY casually when the recipient should only see current-state data; retention and historical-data exposure become part of the sharing contract.<\/p>\n

Usage tracking and audit should drive recertification<\/h3>\n

Provider and recipient activity can be audited through Unity Catalog\/system tables and sharing metadata.<\/p>\n

Review who still consumes a share, which assets are queried, whether credentials are approaching expiry, and whether the business agreement remains active.<\/p>\n

Inactive recipients should be revoked rather than left indefinitely because \u201cthe share is read-only.\u201d<\/p>\n

Asset lifecycle must include schema and policy changes<\/h3>\n

A shared table can evolve after the consumer integrates with it. Column removal, type changes, renamed views, ABAC policy changes, deletion-vector\/table-feature upgrades, or retention changes can break recipients.<\/p>\n

Publish version\/change notices and test external consumers for protocol compatibility before major table changes.<\/p>\n

Sharing turns internal schemas into external contracts.<\/p>\n

OpenSharing governance succeeds when external access remains a first-class data product<\/h3>\n

The mature provider uses narrow shares, strongly identified recipients, OIDC\/native sharing where possible, short\/rotated bearer tokens where necessary, delegated Unity Catalog privileges, explicit history\/policy behavior, usage review, and a decommissioning process.<\/p>\n

Renaming Delta Sharing to OpenSharing reflects a broader standard; governance still comes from knowing exactly what leaves the organization and why.<\/p>\n

Share design should distinguish current-state data from full history. A recipient who needs analytics on the latest table usually does not need every historical Delta version. Sharing WITH HISTORY can improve some high-performance access patterns, but it also broadens what the recipient can inspect and increases the importance of VACUUM, deleted-data retention, and change-log governance.<\/p>\n

Partition filters or dynamic views can reduce exposure when a recipient needs only a region, customer segment, or product domain. Prefer sharing the minimum authorized slice rather than sending a whole table and asking the recipient to ignore unrelated rows. The producer remains responsible for what is made available through the share.<\/p>\n

Provider ownership should survive employee turnover. Shares and recipients should be owned by groups or service principals where the platform permits, with clear business\/product owners in metadata. A departing employee should not strand an external data contract or leave nobody able to rotate a recipient credential.<\/p>\n

Recipient IP allowlists and network controls should be used when the external consumer’s access pattern is predictable. These controls supplement authentication and reduce exposure if a token or recipient identity is compromised. Review allowlists during office\/network changes so security does not silently break the recipient’s production workload.<\/p>\n

Schema evolution should be managed as an external API. Additive columns may be harmless, while type changes, renames, column drops, or feature-table protocol upgrades can break clients. Publish deprecation notices and provide a transition period when shared datasets have contractual consumers.<\/p>\n

Data classification should travel with the sharing decision. Unity Catalog tags\/comments can help providers identify PII, confidential, export-controlled, or regulated fields before adding an asset to a share. Sharing approval should include both asset classification and recipient purpose, not merely the technical ability to grant SELECT.<\/p>\n

Audit should include token rotation and recipient status. A recipient that has not queried for months may no longer have a business need, and a bearer token near expiry can cause an avoidable outage. Build periodic recertification that reviews share contents, recipient authentication type, token expiry, last use, owner, and contract end date.<\/p>\n

OpenSharing should be compared with Clean Rooms and Marketplace for each use case. Direct sharing fits controlled data delivery, Databricks Clean Rooms<\/a> fits joint computation without raw-data trust, and Marketplace fits productized distribution. Governance improves when the organization chooses the mechanism that matches the collaboration rather than using one feature for every external-data scenario.<\/p>\n

Provider-side share composition should be tested under least-privilege identities, not only metastore administrators. A share owner may see assets successfully while the designated automation role lacks USE SHARE or SET SHARE PERMISSION. Validate the exact operational role that will add assets, rotate recipients, and grant access.<\/p>\n

OIDC federation should be preferred where recipient infrastructure supports it because identity lifecycle can be integrated with the recipient’s provider rather than distributing static bearer files. Document issuer\/audience\/subject constraints and test key rotation so federation does not become a hidden single point of failure.<\/p>\n

Shared models and notebooks introduce different risk from read-only tables. A model can embody licensed weights or proprietary logic; a notebook can expose code and assumptions. Classify non-tabular assets separately and grant them only to recipients whose contract explicitly covers those artifacts.<\/p>\n

OpenSharing performance optimization should not override governance. Directory\/cloud-token access can make large table reads faster, but if sharing full history reveals deleted records or sensitive commit metadata, use another sharing mode or a curated view even if it is slower. Data minimization is more important than maximum read throughput.<\/p>\n

Decommissioning should be reversible during a short confirmation window but decisive afterward. Revoke share access, rotate\/revoke tokens, notify the recipient, and confirm workloads have stopped. Then remove obsolete recipient\/share objects according to audit-retention policy so old relationships do not remain as discoverable or accidentally reusable configuration.<\/p>\n

Recipient onboarding should include a technical acceptance test. Verify catalog mounting\/import, representative table reads, history behavior where enabled, token or OIDC authentication, IP restrictions, and expected denied assets before the recipient depends on the share in production. A successful GRANT is not proof the end-to-end sharing contract works.<\/p>\n

Provider and recipient organizations should agree on incident contacts and change windows. External consumers cannot debug your table policy, token rotation, or schema migration from inside their environment. A small operating agreement covering outage notification, planned breaking changes, and credential incidents turns the share into a supportable data product.<\/p>\n","protected":false},"excerpt":{"rendered":"

Delta Sharing has been renamed OpenSharing in current Databricks product documentation following the 2026 release of the open-source OpenSharing standard. The approved title uses the familiar older name, but new governance design should use current OpenSharing terminology and APIs. The service is built on Unity Catalog securables\u2014shares, recipients, and providers\u2014to expose governed data and AI […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-19941","post","type-post","status-publish","format-standard","hentry","category-general"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t