On June 10, 2026, Databricks and the Linux Foundation announced OpenSharing, a vendor-neutral successor to Databricks' Delta Sharing protocol, built to extend zero-copy sharing beyond tables to models and AI agents (Databricks, 2026; Linux Foundation, 2026). The announcement is a good prompt to explain a piece of infrastructure that has quietly become standard across every major warehouse and lakehouse: sharing data with another team, company or cloud without copying it.
What zero-copy data sharing actually is
For most of the data warehouse era, getting data from one system to another meant moving it. An ETL job extracted rows, wrote them to a file or a staging table, and loaded them into the destination. Every hop added latency, storage cost and a second copy that could drift out of sync with the source.
Zero-copy sharing removes the copy. Instead of exporting rows, the provider grants the consumer permission to query the data directly, either through a live reference to the same underlying storage or through a metadata layer that points at one shared set of files. The data lives in one place. The provider controls who can query it and can revoke access, but never hands over a file.
Every major platform now ships some version of this:
Snowflake popularized the pattern with Secure Data Sharing, which shares data through metadata pointers within Snowflake's platform. Its Egress Cost Optimizer, made generally available in April 2025, cuts the cost of replicating shared data to additional regions by caching it after the first transfer, which Snowflake says can reduce cross-region egress costs by up to 96% (Snowflake, 2025).
Databricks built Delta Sharing as an open protocol rather than a proprietary feature. Databricks says Delta Sharing now has more than 28,000 data recipients and is used by Amadeus, Atlassian, LSEG, SAP, Stripe and TheTradeDesk, among others (Databricks, 2026). OpenSharing extends that same open-protocol approach to AI models and agents.
Amazon Redshift supports data sharing between clusters and across AWS accounts without copying or moving data, using a producer-consumer model that requires the consumer account to accept a handshake before it can query (AWS, 2026).
Google BigQuery offers Analytics Hub, which lets an organization publish a dataset as a listing that other organizations subscribe to, again without physically moving the underlying data (Google Cloud, 2026).
The mechanism differs by vendor, but the outcome is the same: one copy of the data, multiple parties querying it under access controls the provider sets.
Why it exists
Two costs drove this. The first is cloud egress pricing. Moving data out of AWS to the internet costs $0.09 per gigabyte for the first 10 terabytes a month, stepping down at higher volumes, and cross-region transfers are commonly billed on both ends (AWS Partner Network, 2026). At the volumes enterprise data platforms move, that recurs every time a copy is refreshed and adds up fast.
The second is staleness. A copied dataset is correct at the moment it is copied and wrong the moment the source changes. Any team running analysis against a copy is implicitly deciding how much drift it can tolerate before the numbers are wrong enough to matter.
Zero-copy sharing addresses both: no second copy to pay egress on, and no staleness because there is only one version of the data to query.
Where the approaches genuinely differ
The single biggest fork is proprietary versus open protocol. Snowflake's Secure Data Sharing works across Snowflake accounts and, through Cross-Cloud Auto-Fulfillment, across Snowflake deployments on different clouds, but the consumer generally needs to be on Snowflake. Delta Sharing was built the opposite way. The protocol is open, and Databricks publishes open-source connectors so a consumer on Spark, pandas or a BI tool can read a share without running Databricks at all. That is the basis of Databricks' claim that a third of Delta Sharing traffic now flows through open, non-Databricks connectors (Databricks, 2026).
The second fork is scope. Redshift's data sharing and BigQuery's Analytics Hub are built for sharing tables within their own ecosystem or, with added configuration, across accounts in the same cloud. Cross-cloud sharing between, say, a BigQuery consumer and data sitting in Amazon S3 increasingly works through open table formats like Iceberg rather than through either vendor's native sharing feature (AWS, 2026). OpenSharing is explicitly a bet that the next fight is over sharing AI models and agent configurations, not just tables, something none of the table-focused sharing features were built for.
What to look at when evaluating this
Four questions matter more than the marketing copy.
Does the consumer need to run the same platform as the provider? If a partner, customer or internal team on a different stack cannot read the share without migrating, the zero-copy claim still carries a lock-in cost, just not a storage one.
What happens across regions and clouds, not just accounts? Same-cloud, same-region sharing is solved everywhere. Cross-region and cross-cloud sharing is where egress costs and latency still show up, and where a vendor's own cost optimizer, like Snowflake's ECO, matters most.
Who can revoke access, and how fast? Zero-copy sharing means the provider can cut off a consumer instantly since no copy is already sitting on the consumer's disk. Confirm that revocation actually works that way in the product, not just in the documentation.
Is governance shared or duplicated? A share is only as good as the access controls and audit log behind it. If the provider's row-level security and column masking do not carry through to the shared view, the consumer is querying a less-governed copy of governed data, which defeats the point.
What commonly goes wrong
Teams sometimes treat zero-copy sharing as a replacement for a data contract rather than a transport mechanism. Removing the copy step does not remove the need to agree on schema stability, update frequency and what a null means. A share with an undocumented schema change breaks a consumer's pipeline exactly as fast as a bad CSV export did.
The other common failure is assuming zero-copy means zero cost. Compute still runs against the data every time a consumer queries a share, and depending on the platform, that compute is billed to the consumer, the provider, or split by agreement. A share that gets queried constantly by a data-hungry partner can still show up as a real cost line, just a compute one instead of a storage one.
Sources: Databricks Announces OpenSharing — Databricks · Linux Foundation Announces OpenSharing Project — Linux Foundation · Optimizing Data Transfer Costs with Egress Cost Optimizer — Snowflake · Snowflake Egress Cost Optimizer (GA) — Snowflake · Sharing Data Across AWS Accounts — Amazon Redshift Documentation · AWS Data Transfer Charges — AWS Partner Network Blog · Enable Cross-Cloud Analytics with Amazon S3 Tables and Google BigQuery — AWS Big Data Blog · BigQuery Analytics Hub Documentation — Google Cloud