Databricks renamed DeltaSharing to OpenSharing and handed it to the Linux Foundation — the same three-object model, now with agent skills, ML models, and Iceberg-native recipients.
Databricks renamed DeltaSharing to OpenSharing in June 2026 and handed it to the Linux Foundation as a standalone project. That kind of announcement usually comes bundled with new complexity and a fresh set of concepts to learn before you can use any of it. OpenSharing is the rare exception. It adds real capability and still runs on the same three-object model that made DeltaSharing simple in the first place.
Delta Shares were created to share data within Delta tables from Databricks to any other platform or consumer. This was quickly open-sourced for use outside of Databricks. Databricks continued to work on the project and expanded it for more governed shares with Unity Catalog access controls. The transition to OpenSharing moves beyond just Delta tables and into a truly open protocol for sharing.
Shareable asset types expanded beyond tables and views. A share can now include agent skills, ML models, and your Genie agent conversation, alongside unstructured data that DeltaSharing already supported through volumes. A provider with a proprietary agent skill, like a specialized retrieval workflow or a domain-tuned tool, can publish it once and let any partner's agent consume it through standard discovery and authorization APIs. The same can be done with trained ML models. Before this, getting those kinds of assets into a partner's hands meant packaging files, sending them manually, and repeating the process for every update to the asset.
Iceberg REST Catalog clients can now act as recipients. Previously, consuming a share required a client that spoke the DeltaSharing protocol. Organizations running Iceberg-native tooling can now pull from the same shares without switching platforms, expanding the reach for providers without needing separate integrations for each type of recipient.
Governance moved to the Linux Foundation. OpenSharing is no longer a Databricks-controlled sub-project of Delta Lake. It's an independent open source project with its own governance, which matters a lot if you ever need to justify a build based on a vendor-controlled standard to a security or procurement team.
None of this breaks anything. Existing DeltaSharing deployments keep running exactly as configured, and everything below describes the same workflow whether you set up sharing in 2023 or you are starting today.
OpenSharing and its new features ride the same three objects: a share, a recipient, and a grant. A share is a named bundle of assets in your Unity Catalog metastore. A recipient represents whoever is on the other end, whether that's another Databricks workspace, an Iceberg-native platform, or an external system with no Databricks account.
Adding an agent skill to a share uses the same flow as adding a table. There's no separate console, no new object type to provision, no additional concept to learn before you can share a model instead of a dataset.
That consistency is the actual headline here. Databricks could have shipped agent skill sharing as a bolted-on feature with its own permission model and its own setup path. Instead, it extended the definition of what a share can hold, which means anyone who understands Delta Sharing understands how to share an AI model with OpenSharing.
When both sides run Unity Catalog, which covers most partner relationships between companies already on Databricks, you don't need to manage any credentials. The recipient sends you an OpenSharing ID (Sharing Identifier) from their own Unity Catalog that you paste in when you create the recipient object and grant the share.
Sharing with a recipient outside Unity Catalog, like an Iceberg-native platform or a plain client with no Databricks workspace, uses a bearer token or OpenID Connect federation. Databricks generates the credential and packages an activation link that you send to the recipient. This path carries ongoing responsibility around token lifetime and rotation that the Databricks-to-Databricks path avoids, but the share and grant steps underneath are identical. The extra work lives entirely in credential management, not in learning a different sharing model for each recipient type.
The clearest use case is the one Databricks called out at launch: a provider with a proprietary agent skill can publish it once and reach every partner's agent through the same protocol, saving six weeks of point-to-point integration work for each new customer. The same logic applies to a model that multiple business units or external partners need to consume without each of them standing up their own copy, and to data that needs to be used across multiple platforms.
Beyond sharing agentic assets, we now have a clean method of sharing to and from on-prem systems that use the OpenSharing protocol for global distribution. This unlocks the ability to share assets that used to flow through S3 buckets, Slack messages, emails, and many other unsafe mechanisms. Now you can share them seamlessly through OpenSharing and ensure that only the desired recipients receive your asset.
None of these are edge cases that you would only encounter after months of using the platform. They are everyday issues, and OpenSharing's architecture means that you can resolve all of them with the same create-a-share, create-a-recipient, grant-access sequence of the original DeltaSharing workflow.
If you already have DeltaSharing running, there's no migration needed. With the transition to OpenSharing, the platform can now carry models and AI assets as well as tables. No migration or configuration update for the platform is required, unless you need the newly added features.
See the release here: https://www.databricks.com/blog/introducing-opensharing-next-evolution-delta-sharing-agentic-era
Read more about the latest and greatest work Rearc has been up to.
Databricks renamed Delta Sharing to OpenSharing and handed governance to the Linux Foundation. Here is what actually changed under the hood, and why the same three-object model still applies.
Photon and AQE (Adaptive Query Execution) make the work you already do faster. The Delta transaction log decides how much work exists at all — here are five levers you can read straight out of _delta_log/ and the fixes each one points to.
Databricks' Genie Ontology and OntoRank solve the problem of trust, not accuracy. Here's why ranking authority isn't the same as checking math.
A data engineer's first-hand look at Databricks' Lakewatch SIEM training, covering ingestion presets, detection engineering, and how a lakehouse-native architecture closes the coverage gaps that open during SIEM migrations.
Tell us more about your custom needs.
We’ll get back to you, really fast
We will evaluate your query and respond within 2 business days.
Kick-off meeting
We will schedule a quick meeting to further understand your use case and start working toward a solution together!
