Zero copy data sharing lets one organisation grant another live, governed access to its data without moving or duplicating a single byte. Instead of exporting files or running ETL jobs, the data stays in the owner’s storage while the consumer queries it directly through a share, a REST catalog, or a signed pointer, cutting duplication, staleness, and storage cost.
| Approach | How data moves | Freshness | Governance model | Typical cost driver |
|---|---|---|---|---|
| Traditional export / ETL | Full or incremental copy written to files, then loaded into a second system | As stale as the last batch job | Re-implemented separately in each downstream system | Storage duplication plus compute for every copy |
| Snowflake Secure Data Sharing | Metadata pointer grants access to the same physical tables, no copy created | Live, reflects the source at query time | Grants and row policies managed centrally by the provider account | Compute consumed by the consumer’s own warehouse |
| Databricks Delta Sharing | Open REST protocol issues short-lived signed URLs to Delta or Parquet files | Live, consumers read the current table version | Recipient tokens and table-level grants managed by a sharing server | Object storage requests from the provider’s cloud account |
| Apache Iceberg REST catalog | Cross-account engines resolve the same catalog and read table metadata directly | Live, any engine sees the latest snapshot | Catalog-level access control, engine-agnostic | Object storage requests plus optional cross-cloud transfer |
What Zero-Copy Data Sharing Actually Means
Zero-copy data sharing is a pattern where a data owner grants a consumer direct, governed read access to a dataset without physically transferring it into the consumer’s own storage or database. The consumer queries a pointer, a catalog entry, or a signed reference that resolves back to the same underlying files or tables the owner manages. Nothing is exported, no pipeline copies rows overnight, and no second storage bill accumulates for the same information.
This is a meaningful departure from how cross-organisation data exchange has worked for the past two decades. Historically, sharing data with a partner, supplier, or subsidiary meant building a file drop, an API extraction job, or a replicated table in a shared warehouse. Each of those methods creates a copy. Copies drift out of sync, inherit their own access rules, and multiply the attack surface a security team has to defend. Zero-copy approaches collapse that complexity by keeping a single authoritative copy and layering access control on top of it.
The mechanics differ by platform, but the underlying idea is consistent: separate the concept of ownership from the concept of access. The owner keeps physical custody, versioning, and lifecycle control. The consumer gets a live view scoped by grants, row policies, or column masks, and that view updates automatically as the source changes.
Why Traditional Cross-Organisation Data Sharing Breaks Down
Before evaluating the newer platforms, it helps to understand precisely why file exports and custom ETL pipelines stop scaling once more than two or three partners are involved.
The Hidden Cost of Duplicate Copies
Every export creates a new copy that needs its own storage, its own backup policy, and its own security review. A single dataset shared with five partners through file transfers becomes six copies of the truth: the source and five downstream replicas. Storage costs grow linearly with the number of consumers, and so does the operational burden of monitoring each pipeline for failures. Teams that have already read our comparison of AWS S3, Google Cloud Storage, and Azure Blob know that object storage pricing scales with both capacity and retrieval patterns, and duplicate copies inflate both.
Staleness and Reconciliation Problems
Batch exports run on a schedule, typically nightly or hourly. Anything that changes at the source between runs is invisible to the consumer until the next job completes. When two partners each build their own reporting on top of a stale copy, small timing differences turn into reconciliation disputes that consume analyst hours. Zero-copy sharing removes this class of problem entirely because the consumer reads the current state, not a snapshot from several hours ago.
Governance Fragmentation
When data is copied into a partner’s environment, the owner loses the ability to enforce row-level security, column masking, or revocation after the fact. Once a file has left the building, it is out of reach. This is one reason enterprise privacy teams, including the roles described in our overview of data privacy officer responsibilities, increasingly push for access-based sharing models where a single revoke action instantly cuts off a partner rather than requiring a chase for deleted files across unknown systems.
Figure 1: Copy-based sharing versus zero-copy sharing
In a copy-based flow, the source system exports a file, a pipeline lands it in the partner’s storage, and the partner’s own access controls take over from that point forward, with no further connection back to the source. In a zero-copy flow, the partner’s compute engine issues a query that resolves through a share, a signed URL, or a REST catalog entry directly against the owner’s storage, so every read passes through the owner’s live governance layer.
The essential difference is where enforcement happens: at export time versus at query time.
How the Major Zero-Copy Platforms Work
Four approaches currently dominate production deployments of cross-organisation zero-copy sharing. Each solves the same problem with a different architectural bet.
Snowflake Secure Data Sharing
Snowflake’s Secure Data Sharing feature lets an account owner create a share object that references specific databases, schemas, or tables and grant that share to another Snowflake account, even one belonging to a different organisation. The consuming account mounts the share as a read-only database. No data is copied between accounts; the consumer’s compute simply reads the same underlying micro-partitions the provider owns, subject to whatever grants and secure views the provider has defined. Because Snowflake separates storage from compute, the provider pays for storage while each consumer pays for its own compute when it queries the share.
Databricks Delta Sharing
Delta Sharing is an open protocol, originally created by Databricks and later contributed to the Linux Foundation, for sharing data stored as Delta Lake or Parquet tables. A sharing server issues short-lived, pre-signed URLs that point directly at the underlying cloud storage objects, so any client that speaks the open REST protocol can read the data, regardless of vendor. This vendor-neutral design is the main differentiator from Snowflake’s approach: a Delta Sharing recipient does not need to run Databricks at all, they can connect with Power BI, pandas, Spark, or any other Delta Sharing-compliant client.
Apache Iceberg REST Catalog Cross-Account Access
Apache Iceberg standardises table metadata in a way that lets multiple compute engines, Spark, Trino, Flink, and others, read and write the same table concurrently. The Iceberg REST catalog specification extends this further by defining a standard HTTP API for catalog operations, which means an organisation can expose a catalog endpoint that a partner’s engine, running in a completely different cloud account, can query to resolve the current snapshot of a table and read its underlying data files. As long as network access and object storage permissions are configured correctly, no data ever needs to be copied between accounts, only catalog metadata is exchanged over the REST interface.
AWS Data Exchange for S3
AWS Data Exchange started as a marketplace for subscribing to third-party datasets, but its S3-based entitlement model now supports zero-copy access to data that stays in the provider’s own S3 buckets. Subscribers query provider data in place using AWS analytics services, rather than receiving a delivered copy, and the provider retains control over which prefixes and objects are entitled to which subscriber.
| Scenario | Best-fit approach | Why |
|---|---|---|
| Both organisations already run Snowflake | Snowflake Secure Data Sharing | Zero setup beyond a grant; consumer uses native SQL and existing compute |
| Partner uses a different platform or tool entirely | Delta Sharing | Open protocol works with any REST-capable client, no vendor lock-in |
| Multiple engines need to write and read the same table | Iceberg REST catalog | Engine-agnostic table format avoids duplicating pipelines per engine |
| Publishing a commercial dataset to many subscribers | AWS Data Exchange for S3 | Built-in entitlement, billing, and marketplace discovery |
Governance and Security Considerations
Removing the copy does not remove the need for governance, it relocates it. The owner’s access control layer becomes the single point of enforcement for every consumer, which is a bigger responsibility than managing a one-off export job.
Access Control and Row-Level Policies
Secure views, dynamic data masking, and row-access policies let a provider expose the same physical table to different partners with different visible slices. A supplier might see only its own transaction rows, while a regulator sees an aggregated view. This pattern only works cleanly when the underlying platform supports policy enforcement at query time, which is exactly what Snowflake shares, Delta Sharing recipients, and Iceberg REST catalogs are designed around.
Auditing Cross-Organisation Queries
Because every read passes through the provider’s infrastructure, query logs capture exactly who accessed what and when, across organisational boundaries. This is a meaningfully stronger audit trail than a file export, where the provider loses visibility the moment the file lands in the partner’s environment. Organisations mapping out open banking data-sharing frameworks increasingly cite this audit continuity as a compliance advantage over file-based delivery.
Figure 2: A three-partner share topology
One provider account maintains three separate shares, one per partner, each scoped to a different subset of tables and rows. A manufacturing partner sees inventory and shipment tables filtered to its own supplier code. A logistics partner sees delivery and route tables filtered to its own contracted lanes. A finance partner sees invoice tables with customer identifiers masked. All three shares point at the same underlying physical storage, so the provider maintains one copy of the data while enforcing three distinct views.
Scoped shares let one dataset serve many partners without proliferating physical copies.
Implementation Playbook
Standing up a zero-copy share between two organisations follows a fairly consistent sequence regardless of which platform is chosen.
Step 1: Classify and Scope the Dataset
Identify exactly which tables, columns, and rows the partner is entitled to see. This step is where most governance failures originate, because it is tempting to share an entire schema for convenience rather than scoping tightly.
Step 2: Apply Masking and Row Policies Before Granting Access
Build the secure view, dynamic mask, or row policy first, then grant access to the restricted view rather than the raw table. Granting broad access and tightening later is a common source of accidental over-exposure.
Step 3: Configure the Share or Catalog Entitlement
Create the share object, issue the Delta Sharing recipient token, or register the Iceberg REST catalog credential. Document an expiry or review cadence for every credential issued to an external party.
Step 4: Validate the Consumer’s Read Path
Confirm the partner can resolve the share, query a sample, and see only the intended rows. Run this validation from an account that mirrors the partner’s actual permission set rather than an admin account.
Step 5: Monitor Query Volume and Access Patterns
Set alerts for unusual query volume or access outside expected hours, since a compromised partner credential now has a live path into production data rather than a stale export.
Expert practice
Experienced data platform teams treat every external share the same way they treat a production API: versioned, documented, and reviewed on a schedule. A common practice is to require a written data-sharing agreement that specifies which columns are shared, how long the grant remains active, and who owns renewal, before any share object is created. Teams that skip this step tend to accumulate shares nobody remembers granting, which becomes a liability during a security review. Pairing the technical share with a lightweight big data analytics pipeline that logs consumer query patterns gives the provider an early warning system for unusual access well before a formal audit would surface it.
Common mistakes
Sharing an entire schema instead of a scoped view because it is faster to set up initially, then struggling to retrofit row-level policies once partners depend on the broad access. Forgetting that a consumer’s compute costs are the consumer’s responsibility, which can create billing disputes if this was never made explicit in the sharing agreement. Treating a share as a one-time setup task rather than an ongoing relationship that needs periodic access reviews and credential rotation. Assuming zero-copy sharing eliminates egress costs entirely, when in practice cross-cloud reads through Delta Sharing or Iceberg REST catalogs can still incur transfer charges depending on where the consumer’s compute runs relative to the provider’s storage region.
Cost and Egress Realities
Zero-copy sharing reduces storage duplication, but it does not automatically make cross-organisation data access free. When a consumer’s compute engine runs in a different cloud region or a different cloud provider than the data’s storage location, the read still crosses a network boundary and can trigger transfer charges. Organisations that have already mapped their multi-cloud adoption patterns are best positioned to plan for this, since they already track which workloads span providers. The practical takeaway is that zero-copy sharing shifts cost from storage duplication toward query-time compute and, in cross-cloud cases, network transfer, which is usually a better trade but still needs to be budgeted.
Glossary
- Zero-copy data sharing
- A method of granting access to a dataset without duplicating the underlying data into the consumer’s own storage or database.
- Secure Data Share
- Snowflake’s native object that grants a read-only reference to specific tables or views in one account to another account.
- Delta Sharing
- An open REST protocol for sharing Delta Lake and Parquet tables across organisations and platforms without copying files.
- Iceberg REST catalog
- A standardised HTTP API that lets different compute engines resolve and read the same Apache Iceberg table metadata.
- Metadata pointer
- A reference that resolves to the location of underlying data files or table snapshots, rather than a copy of the data itself.
- Row-access policy
- A rule that filters which rows of a table a given user, role, or partner account is permitted to see at query time.
- Egress cost
- A charge incurred when data is read across a network boundary, such as between cloud regions or cloud providers.
Key Takeaways
- Zero-copy data sharing grants live, governed access to data in place instead of exporting or replicating it to a partner’s environment.
- Snowflake Secure Data Sharing uses metadata pointers between accounts, so the provider retains storage and the consumer pays only for its own compute.
- Delta Sharing is an open, vendor-neutral protocol, so a recipient does not need to run Databricks to read shared tables.
- The Apache Iceberg REST catalog lets multiple compute engines across different accounts read the same table metadata without copying files.
- Traditional export and ETL sharing multiplies storage cost and introduces staleness because every partner receives its own snapshot.
- Governance moves from export time to query time, which strengthens auditing but makes the provider’s access control layer a single point of enforcement.
- Zero-copy sharing reduces duplication cost but does not eliminate cross-cloud transfer charges, so budgeting for query-time compute and network paths still matters.
FAQs
What is the main difference between zero-copy data sharing and traditional data export?
Traditional export writes a physical copy of the data into the partner’s own storage or database, which then drifts out of sync with the source. Zero-copy sharing grants a live reference or pointer that the partner’s compute engine queries directly, so there is only ever one physical copy and the consumer always sees the current state rather than a stale snapshot.
Does zero-copy data sharing eliminate storage costs entirely?
It eliminates duplicate storage costs for the shared dataset, since only the owner stores a physical copy. However, the consumer still pays for its own compute when querying the shared data, and cross-cloud or cross-region reads can still incur network transfer charges depending on the platform and the location of the consumer’s compute relative to the provider’s storage.
Can I use Delta Sharing if my organisation does not run Databricks?
Yes. Delta Sharing is an open REST protocol, not a Databricks-exclusive feature, and it was contributed to the Linux Foundation specifically to keep it vendor-neutral. Any client that implements the open protocol, including tools like pandas, Power BI, or Spark, can connect to a Delta Sharing server and read the shared tables without running Databricks itself.
How does Snowflake Secure Data Sharing handle row-level security across organisations?
Snowflake lets a provider build secure views with row-access policies or dynamic data masking on top of the base tables, then share the secure view instead of the raw table. Each consuming account only sees the rows and columns the policy permits, and because enforcement happens at query time inside the provider’s account, the provider can update or revoke that policy at any point.
What role does the Apache Iceberg REST catalog play in cross-account data sharing?
The Iceberg REST catalog standardises how compute engines discover and resolve table metadata over HTTP. This lets an engine running in one organisation’s cloud account query a catalog endpoint exposed by another organisation and read the current snapshot of a shared Iceberg table directly from object storage, without any engine-specific integration or data movement.
Is AWS Data Exchange the same thing as zero-copy sharing?
AWS Data Exchange started primarily as a marketplace for subscribing to and receiving delivered datasets, but its S3-based entitlement model now also supports zero-copy access, where subscribers query provider data directly in the provider’s own S3 buckets rather than receiving a copy. Whether a specific listing is delivered or in-place depends on how the provider configured it.
What are the biggest governance risks with zero-copy data sharing?
The main risk is over-scoping a share, granting access to an entire schema instead of the specific rows and columns a partner actually needs. Because the provider’s access control layer becomes the sole enforcement point for every consumer, a misconfigured grant or an unreviewed credential can expose more data than intended, which makes periodic access reviews and credential rotation essential.
How do I choose between Snowflake Secure Data Sharing, Delta Sharing, and an Iceberg REST catalog?
If both organisations already run Snowflake, Secure Data Sharing needs the least setup. If the partner uses a different platform entirely, Delta Sharing’s open protocol avoids vendor lock-in. If multiple engines across organisations need to read and write the same table, an Iceberg REST catalog keeps the table format and access layer engine-agnostic rather than tied to one vendor’s runtime.
- Snowflake, “Introduction to Secure Data Sharing,” Snowflake Documentation, https://docs.snowflake.com/en/user-guide/data-sharing-intro
- Databricks, “Delta Sharing: An Open Protocol for Secure Data Sharing,” Delta Sharing Project, https://delta.io/sharing/
- Apache Software Foundation, “Iceberg REST Catalog Open API Specification,” Apache Iceberg Documentation, https://iceberg.apache.org/rest-catalog-spec/
- Amazon Web Services, “What Is AWS Data Exchange,” AWS Data Exchange Documentation, https://docs.aws.amazon.com/data-exchange/latest/userguide/what-is.html
