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, 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 quickly was open-sourced and could be used outside of Databricks as well, with some tweaking. Databricks continued to work on the project and expanded it for more governed shares utilizing Unity Catalog access controls. Now with the move to OpenSharing, we move beyond just Delta tables and into a truly open sharing protocol.
The asset types expanded well past tables and views. A share can now include agent skills, ML models, and your Genie agent conversation directly, alongside the unstructured data that DeltaSharing already supports through volumes. A provider with a proprietary agent skill, something 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 every time the asset updated.
Iceberg REST Catalog clients can now act as recipients. Previously, consuming a share required a client that spoke the DeltaSharing protocol directly. Now organizations running Iceberg-native tooling can pull from the same shares without switching platforms, which meaningfully widens who a provider can reach without building a separate integration per recipient type.
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 if you have ever had to justify a build on top of 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 identical flow as adding a table. There is 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 under OpenSharing.
When both sides run Unity Catalog, which covers most partner relationships between companies already on Databricks, there is no credential to manage. The recipient hands you an OpenSharing ID (Sharing Identifier) from their own Unity Catalog, you paste it in when creating the recipient object, and you grant the share.
Sharing with a recipient outside Unity Catalog, an Iceberg-native platform or a plain client with no Databricks workspace, uses a bearer token or OpenID Connect federation instead. Databricks generates the credential, packages an activation link, and you send it to the recipient. This path does carry real ongoing responsibility around token lifetime and rotation that the Databricks-to-Databricks path avoids entirely, but the share and grant steps underneath are identical either way. The extra work lives entirely in credential management, not in learning a different sharing model for a different 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.
On top of sharing agentic assets, we now have a clean method of sharing to and from on-prem systems then using the OpenSharing protocol for global distribution. This unlocks the ability to share assets that used to clumsily flow through S3 buckets, Slack messages, emails, and many other unsafe mechanisms. Now you can share them seamlessly through OpenSharing and ensure the exact recipient received your asset.
None of these are edge cases you encounter only after months of using the platform. They're the reason OpenSharing exists in its current form, and every one of them is reachable through the same create-a-share, create-a-recipient, grant-access sequence that has always been the workflow.
If you already have DeltaSharing running, then there's no migration needed. With the change into OpenSharing, the platform now can carry models and AI assets, in addition to supporting tables exactly as before. 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!
