For years, sharing data across organizational boundaries followed a predictable pattern. You copied it. That meant stale data, duplicated storage costs, compliance headaches, and a manual update loop that never quite kept pace with how fast the source changed. Delta Sharing, launched by Databricks in 2021, was the first serious attempt to break that pattern with an open, zero-copy protocol. It worked well for structured data. But the data landscape has shifted.
Organizations now need to exchange more than tables. AI models, agent skills, semantic context, and unstructured data have become core collaboration assets. And the old tools for sharing them are exactly as clunky as the old tools for sharing data were: custom integrations, emailed files, and bilateral agreements that take weeks to set up for each new partner.
Databricks announced OpenSharing on June 10, 2026, as the direct response to that problem. It extends Delta Sharing into a full protocol for the agentic era , now hosted by the Linux Foundation and covering the entire AI stack. In this article, we’ll cover what OpenSharing is, how it works technically, where it fits relative to Delta Sharing, and what it means for enterprise data teams.
Key Takeaways OpenSharing is the evolution of Delta Sharing, announced June 2026, now hosted by the Linux Foundation and covering data, AI models, agent skills, and unstructured data. The protocol uses zero-copy credential vending, meaning recipients query data directly from the provider’s cloud storage without any data movement. Unity Catalog enforces governance end-to-end, including row- and column-level controls, audit logs, and compliance policies that travel with every shared asset. OpenSharing supports Apache Iceberg REST Catalog API clients, significantly broadening who can receive shared assets beyond the Delta Sharing ecosystem. On-premises and private-cloud connectivity is now available through storage partners including MinIO, Qumulo, and Everpure, removing the data movement barrier for regulated industries.
From Delta Sharing to OpenSharing: What Changed Delta Sharing launched in April 2021 as a sub-project within Delta Lake. Its core idea was simple: let organizations share live data across platforms without copying it. Recipients could access Delta Lake and Parquet tables through an open protocol using short-lived bearer tokens or OIDC federation. No platform lock-in. No replication. That model worked, and adoption followed. Databricks reports that Delta Sharing became the most widely adopted open data-sharing protocol, with organizations including Amadeus, Atlassian, LSEG, SAP, Stripe, and The Trade Desk using it in production.
The gap Delta Sharing left was not in structured data sharing. It was in everything else. When organizations started building multi-agent AI systems , they ran into the same fragmentation problem they once had with data, but now with agent skills and AI models. There was no standard way to share an agent skill across organizational boundaries. A team would email a file. Then email an update. Then email another update. The problem scaled poorly. OpenSharing was built to solve that.
OpenSharing extends the Delta Sharing protocol in three concrete directions: it covers the full AI asset stack beyond tables; it adds Apache Iceberg REST Catalog API support so that Iceberg-native recipients can participate; and it connects on-premises and private-cloud storage environments through a growing partner ecosystem. Existing Delta Sharing deployments are not affected. OpenSharing is additive, not a replacement, and introduces no breaking changes for current users.
How Databricks OpenSharing Works OpenSharing operates on zero-copy credential vending. When a provider shares a dataset or AI asset, they do not move the data to a neutral location. Instead, the protocol sends recipients temporary, scoped credentials that let them query the asset directly from the provider’s cloud storage . The data never leaves the provider’s environment. This eliminates the storage duplication costs and compliance risks that come with traditional file-based sharing.
1. The Provider-Recipient Model Every OpenSharing transaction involves a provider and a recipient. The provider creates a share in Unity Catalog , defining which datasets, models, or agents to include and setting fine-grained permissions. The recipient receives credentials and queries the share using their existing tools. They do not need a Databricks account, though Unity Catalog-enabled workspaces get additional features like governance tracking and usage auditing on both sides.
Unity Catalog manages access control throughout the process. It enforces row- and column-level filters, tracks every access in an audit log , and ensures compliance policies travel with the shared asset. If a provider later revokes access, the recipient’s credentials become invalid immediately. There is no orphaned data sitting in a third-party system.
2. Directory-Based Access Mode For eligible Delta tables shared through the Databricks-to-Open protocol, OpenSharing uses directory-based access mode. The platform returns the table’s cloud storage location alongside temporary cloud credentials. Recipients can read directly from that storage location for the duration of the credential window. This is faster than pre-signed URL access and is enabled by default for newly shared assets that meet the eligibility requirements.
For streaming use cases, OpenSharing supports Apache Spark Structured Streaming. A provider can share a table with full history, and recipients can use it as a streaming source, processing data incrementally with low latency . Delta Lake time travel queries also work on tables shared with history, giving recipients the ability to inspect past states of the data.
3. Authentication Options Two authentication paths are available. Bearer token-based authentication generates a credential file and activation link that the provider sends to the recipient over a secure channel. OIDC federation is the more modern option, where the recipient authenticates through their own identity provider, such as Azure Entra ID or Okta. No token-based credentials are exchanged; the IdP manages authentication based on a policy created by the provider. This is particularly useful for regulated environments where third-party credential files raise compliance concerns.
Three Sharing Modes in OpenSharing OpenSharing supports three distinct sharing modes, each suited to different organizational contexts. Understanding which mode applies to a given situation matters before you start building a sharing architecture .
1. Databricks-to-Databricks Both provider and recipient have Unity Catalog-enabled Databricks workspaces. This is the richest mode. It supports sharing notebooks, volumes, AI models, and Genie Agents in addition to tables and views. Governance, auditing, and usage tracking work on both sides. The recipient’s workspace gets access through their metastore’s unique sharing identifier, and no token-based credentials are required. This mode is the recommended path when both parties are on Databricks and want full governance coverage.
2. Databricks-to-Open The provider uses a Unity Catalog-enabled Databricks workspace, and the recipient uses any other compute platform. This is the mode that powers the cross-platform reach Delta Sharing was known for. Recipients can include Apache Spark, pandas, Power BI, Tableau, Snowflake, DuckDB, and a wide range of other tools. Shared assets are tables in Delta format. Access uses either bearer tokens or OIDC federation. This mode is the right choice when the recipient’s platform is not Databricks.
3. Customer-Managed Open Source Any organization can deploy their own OpenSharing server using the open-source implementation available on GitHub. This mode supports sharing from any platform to any platform, regardless of whether either side uses Databricks. It is suited for organizations that want to build OpenSharing into their own infrastructure without depending on the Databricks-hosted server. The Linux Foundation hosts the protocol specification, and any vendor or community member can implement it.
Sharing Mode Provider Requirement Recipient Requirement Asset Types Supported Best For Databricks-to-Databricks Unity Catalog workspace Unity Catalog workspace Tables, views, volumes, notebooks, models, agents Full governance on both sides Databricks-to-Open Unity Catalog workspace Any platform (Spark, Power BI, Snowflake, etc.) Delta tables Cross-platform reach Customer-Managed OSS Any platform Any platform Tables (Delta / Parquet / Iceberg depending on implementation) Platform-agnostic deployments
How OpenSharing Supports AI-Era Data Sharing The structural extension in OpenSharing is the ability to share AI assets using the same governed, zero-copy model that worked for data . Three capabilities stand out.
1. Sharing Agent Skills and AI Models Before OpenSharing, there was no standard protocol for sharing an agent skill across organizational boundaries. The practical workaround was to email a file to each partner and then email updates whenever the skill changed. That approach does not scale. OpenSharing gives organizations a single protocol with standard APIs for discovery, authorization, and access. A data provider publishes an agent skill once. Recipients query it live. Updates propagate automatically without additional file transfers.
Genie Agents , Databricks’ AI-powered conversational analytics environments, can now be shared via OpenSharing with governance controls intact. Providers can hide proprietary Genie instructions from recipients, restrict data access to the agent only, set daily prompt quotas, and cap row export limits. Those controls open a path to usage-based monetization models, where a data provider charges for access to an agent rather than licensing the underlying data directly.
2. Apache Iceberg Interoperability Delta Sharing’s existing ecosystem covers Databricks, Tableau, Power BI, Apache Spark, and Snowflake among others. OpenSharing adds support for Apache Iceberg REST Catalog API clients , which means providers can now reach a new set of recipients operating Iceberg-native tools. Providers can also bring in tables from external catalogs including AWS Glue, Hive Metastore, and Snowflake Horizon, bringing that data into the governed OpenSharing ecosystem without replication.
For data engineering teams that manage mixed Delta and Iceberg environments, this removes the format conversion step from cross-organizational sharing workflows. The same share can serve Delta-native clients and Iceberg-native clients from a single source.
3. On-Premises Connectivity Regulated industries and organizations with significant data gravity have been largely excluded from the benefits of open data sharing protocols because those protocols assumed cloud-resident data. OpenSharing addresses this through a storage partner ecosystem. Partners including MinIO, Qumulo, and Everpure implement the OpenSharing server directly at the storage layer , connecting their on-premises data estates to Unity Catalog without moving data to the cloud. Cohesity, Commvault, NetApp, Nutanix, Rubrik, and VAST Data are expected to follow later in 2026.
The practical path is straightforward: the storage partner stands up an OpenSharing endpoint, the organization connects it to Unity Catalog, and governed access becomes available from within Databricks without a migration. This matters particularly for environments with strict data sovereignty requirements , where moving data to a public cloud is not an option regardless of the analytical value it would produce.
Databricks OpenSharing in Practice: Enterprise Use Cases Understanding the protocol architecture helps. Seeing where it fits in real enterprise workflows helps more. These are the use cases where OpenSharing’s design addresses a specific operational problem.
1. Cross-Organizational Data Products Retailers, financial services firms, and platforms that distribute enriched datasets to suppliers, advertisers, or partners have historically had two options: replicate the data into a shared storage environment or build a custom API for each partner. Both options create ongoing maintenance obligations. OpenSharing lets a provider publish a data product once through Unity Catalog. Partners query it live using their existing tools. The provider governs access centrally, revokes it instantly when a relationship ends, and gets a complete audit trail of every query.
2. Regulated Industry Data Collaboration Healthcare networks, financial institutions, and government contractors often need to share data with external counterparts while maintaining strict controls over where data physically resides. Databricks Clean Rooms, built on OpenSharing, let multiple parties run joint analytics on shared data without either party seeing the other’s raw records. Fine-grained access controls, row-level security , and full audit trails apply across the collaboration. The on-premises connectivity story extends this to organizations where data cannot move to a cloud environment at all.
3. AI Supply Chain Sharing Multi-agent architectures require shared context. When an organization deploys agents that rely on proprietary workflows or domain-specific knowledge, sharing that logic with partner organizations used to mean custom integrations or vendor-specific marketplaces. OpenSharing gives agent skills a governed distribution path. A provider publishes a skill, partners receive live access, and updates propagate automatically. The pattern mirrors how Delta Sharing changed data distribution and applies the same logic to the AI layer.
4. Hybrid Cloud and On-Premises AI Workloads Through the Databricks Storage Ecosystem, organizations can run Serverless Compute , Genie, and LLM workloads directly against on-premises data without copying it first. The storage partner implements the OpenSharing endpoint. Unity Catalog provides governance. The analytical or AI workload runs in Databricks against data that never moves . For organizations managing classified engineering data, regulated financial records, or high-volume network telemetry, this removes the migration step that has historically been the blocker for cloud AI adoption .
OpenSharing and Data Governance Data governance in OpenSharing flows through Unity Catalog. The governance model is hierarchical: the metastore sits at the top, catalogs and schemas organize assets below it, and individual tables, models, and agents sit at the bottom. Privileges are granted to users, groups, or service principals at any level of this hierarchy. A provider who shares a dataset can grant access at the table level, apply row filters, enforce column masks, and set IP access lists that restrict recipient access to specific network locations.
The audit log system captures fine-grained details about every access event, including who accessed a given asset, when, and what actions they performed. Unity Catalog system tables make these logs queryable directly within Databricks. For organizations subject to GDPR, HIPAA, or sector-specific data residency requirements, the combination of zero-copy sharing and full audit lineage addresses the compliance concerns that have made traditional data sharing slow and expensive.
One governance distinction worth noting is that shared catalogs are read-only on the recipient side. A metastore admin or privileged user at the recipient organization creates a catalog from the share. Other users get access to that catalog through standard Unity Catalog permission grants. But no one on the recipient side can write back to the provider’s original data. The single source of truth stays with the provider.
OpenSharing vs. Competing Approaches OpenSharing sits in a space where several other approaches exist. Understanding the differences helps data teams make informed architecture decisions.
1. Proprietary Data Marketplaces Snowflake Marketplace , AWS Data Exchange, and similar platforms let organizations publish and consume data products within a specific ecosystem. The limiting factor is reach. A provider on Snowflake Marketplace reaches Snowflake users. A provider using OpenSharing reaches any organization using any compute platform that supports the protocol. OpenSharing’s Linux Foundation governance also addresses the lock-in concern that applies to vendor-operated marketplaces. Whether that governance model translates into genuine multi-vendor steering committee influence over time is worth monitoring, but the structural intent is clear.
2. Custom API Integrations Building a dedicated data-sharing API for each partner relationship gives maximum flexibility but carries a high build-and-maintain cost. Akram Chetibi, director of product management at Databricks, described the problem clearly to TechTarget : “Everyone was cobbling together their own approach.” OpenSharing replaces bespoke integrations with a standard protocol, removing the per-partner engineering cost. For organizations managing data or AI relationships with dozens of external parties, that reduction in integration overhead is a concrete budget saving.
3. ETL-Based Data Replication Traditional ETL pipelines copy data from source to destination on a schedule. The recipient gets a snapshot, not live data. Data integration tooling has improved significantly, but the fundamental model creates stale data and storage duplication. OpenSharing’s zero-copy architecture means recipients always query the live version of the data at the source. There is no replica to manage and no reconciliation process to run.
What Kanerika Brings to Databricks Implementations Kanerika is a Databricks Consulting Partner with hands-on experience implementing Unity Catalog governance, data sharing architectures , and cross-platform data integration for enterprise clients. The firm works with organizations navigating decisions around OpenSharing adoption, on-premises connectivity, and data modernization strategy . Kanerika holds ISO 27001, ISO 27701, and SOC 2 Type II certifications, and brings governance-first thinking to every data platform engagement.
As a Microsoft Solutions Partner for Data and AI with Analytics Specialization, Kanerika also advises clients on how OpenSharing fits within hybrid environments that include Microsoft Fabric , Power BI, and Azure-based infrastructure. Where OpenSharing’s Iceberg compatibility or on-premises connectivity changes the architecture options for a client, Kanerika’s team can assess the specific implications and design a sharing model that accounts for compliance requirements, existing tooling, and partner ecosystem constraints.
The firm’s broader data modernization practice covers migration from legacy ETL platforms , governance implementation across multi-cloud environments, and AI readiness assessments . Clients that are evaluating OpenSharing as part of a larger data strategy review can work with Kanerika to scope the effort and identify where the protocol addresses real operational pain versus where simpler approaches remain adequate.
Ready to Build a Smarter Data Sharing Architecture? Partner with Kanerika for Databricks consulting, Unity Catalog governance, and cross-platform data integration .
Book a Meeting
Case Study: Eliminating Data Silos and Modernizing Analytics with Databricks The client is one of the largest retail corporations in the United States, operating supermarkets and multi-department stores at national scale. With thousands of store locations and a complex web of business applications dependent on operational data, the organization required a highly reliable, scalable data platform to support enterprise-wide analytics, reporting, and day-to-day decision-making.
Client’s Challenges Distributed on-premise databases created data silos with no centralized lineage, governance, or consistent visibility across business units and downstream applications High infrastructure and maintenance overhead consumed IT capacity in hardware upkeep, backup management, and scaling work that limited focus on analytics and business growth Production application dependencies made a standard cutover approach too risky. So, migration had to run with zero downtime and full parallel availability until each system was verified
Our Solutions Designed a three-phase migration framework using PySpark notebooks and Spark connectors to migrate full historical data from PostgreSQL and Cassandra into Delta Lake tables under Unity Catalog-managed schemas Implemented continuous incremental synchronization using timestamp-based CDC-style logic and Delta MERGE operations, keeping source databases live and current throughout the transition Executed a controlled application cutover phase with parallel system availability, redirecting each application to Databricks workspaces individually after validation, followed by full decommissioning of on-premise infrastructure
Results Zero Downtime, no production interruption 100% Legacy Infrastructure Decommissioned 100% Centralized governance, lineage, and data access
Wrapping Up OpenSharing is a real and well-timed extension of what Delta Sharing started. The zero-copy model, combined with Unity Catalog governance and the new asset types, gives enterprises a structured way to share data and AI artifacts without the usual costs of replication and custom integration. The on-premises connectivity story addresses a gap that has blocked regulated organizations from participating in open data protocols. Whether the full ecosystem of storage partners delivers on latency and security commitments in the second half of 2026 will determine how quickly that use case expands beyond early adopters. For data teams evaluating their sharing architecture now, OpenSharing deserves serious consideration as a foundation layer.
Move Beyond Data Silos with Databricks OpenSharing Work with Kanerika to implement Unity Catalog governance and zero-copy data sharing across your organization.
Book a Meeting
FAQs What Is Databricks OpenSharing? OpenSharing is an open protocol launched by Databricks in June 2026 as the next evolution of Delta Sharing. It allows organizations to securely share data , AI models, agent skills, and unstructured data across platforms and organizational boundaries without moving or copying the underlying assets. It is now hosted by the Linux Foundation as a vendor-neutral open-source project. The protocol works regardless of the compute platform the recipient uses, and Databricks provides an enterprise implementation built on Unity Catalog for governance and audit.
How Is OpenSharing Different From Delta Sharing? Delta Sharing, launched in 2021, focused on sharing structured data tables and Parquet files across platforms without copying them. OpenSharing extends that foundation to cover AI-era assets including agent skills, AI models, and unstructured data. It also adds Apache Iceberg REST Catalog API support, expanding the recipient ecosystem to Iceberg-native tools. On-premises connectivity through storage partners like MinIO and Qumulo is another addition that Delta Sharing did not include. Existing Delta Sharing deployments continue to work unchanged.
Does OpenSharing Require a Databricks Account? Recipients do not need a Databricks account to access data shared via OpenSharing. The Databricks-to-Open protocol lets providers share Delta tables with recipients on any compute platform using bearer tokens or OIDC federation. However, Unity Catalog-enabled Databricks workspaces on the recipient side unlock additional features including governance tracking, audit logging, and usage analytics. The open-source version of the OpenSharing server also allows any organization to run the protocol on their own infrastructure without a Databricks subscription.
Governance in OpenSharing flows through Unity Catalog. Providers set fine-grained permissions at the share level, including row filters, column masks, and IP access lists. Every access event is captured in Unity Catalog’s audit log system tables. Compliance policies travel with the shared asset rather than depending on the recipient’s governance configuration. Shared data is available as read-only to recipients, and provider-side governance remains in effect regardless of what compute environment the recipient uses to query the data.
What Asset Types Can Be Shared Using OpenSharing? OpenSharing supports a broader range of asset types than Delta Sharing. Through the Databricks-to-Databricks protocol, providers can share tables, views, Unity Catalog volumes, AI models, notebook files, and Genie Agents. Genie Agents include their underlying semantic context and business metrics. The Databricks-to-Open protocol currently covers Delta tables. The open-source implementation supports Delta Lake , Parquet, and Apache Iceberg formats depending on the specific connector used by the recipient’s platform.
Can OpenSharing Connect to On-Premises Data? Yes. OpenSharing introduced on-premises connectivity through the Databricks Storage Ecosystem. Storage partners including MinIO (generally available), Everpure, and Qumulo implement the OpenSharing server at the storage layer, connecting on-premises data estates to Unity Catalog without moving data to the cloud. Additional partners including Cohesity, Commvault, HPE, NetApp, Nutanix, Rubrik, and VAST Data are expected to join the ecosystem later in 2026. This capability allows organizations with data sovereignty or regulatory constraints to connect their on-premises data to cloud AI and analytics workloads without migration.
Snowflake offers its own data sharing capabilities through Snowflake Marketplace and Snowflake Horizon Catalog. The primary difference is ecosystem reach. Snowflake-based sharing is strongest when both parties use Snowflake or Iceberg-compatible tools. OpenSharing is platform-agnostic by design and is hosted by the Linux Foundation as an open standard. Providers can also include tables from Snowflake Horizon in OpenSharing through its external catalog support. For organizations that need to share data with recipients across multiple platforms, including non-Snowflake environments, OpenSharing offers broader reach.
Is OpenSharing Suitable for Regulated Industries? OpenSharing’s design addresses several requirements common in regulated industries. The zero-copy model means data never leaves the provider’s environment, which supports data residency and sovereignty requirements. OIDC federation eliminates the need to distribute bearer token files, which reduces credential management risk . Row- and column-level access controls allow providers to share specific data subsets without exposing sensitive fields. The on-premises connectivity option covers cases where data cannot move to a public cloud. For healthcare, financial services, and government use cases, the combination of these controls makes OpenSharing a viable governance-compliant sharing foundation.
