# Data sharing Optional Giving another team or company read access to tables in place, through a sharing protocol or a catalog, instead of sending them exported copies. > [!NOTE] > > **Before reading** > > [Catalogs]() ยท [Row-level security and masking]() ## Why it matters Partners, suppliers, customers and other business units often need data the platform holds. Exports by file or email are easy to start and hard to control: copies go stale, multiply, cannot be revoked and lose their documentation. Sharing in place keeps one copy, current and governed, while the recipient uses their own tools to query it. ## How it works The basic idea relies on the separation of storage and metadata in a lakehouse. The data already sits in open files in object storage. Sharing gives the recipient a way to find which files make up the shared tables, and short-lived permission to read only those files. The recipient's engine reads them directly; nothing is copied, and the provider can revoke access at any time. There are three common mechanisms. Open sharing protocols. Delta Sharing, created by Databricks in 2021, defines a REST protocol in which a sharing server checks the recipient's token and returns the list of files of a shared table with pre-signed URLs, valid for a short time. Recipients can use any client that speaks the protocol, including pandas, Spark and BI tools, without being on the same platform. In June 2026 Databricks announced OpenSharing, hosted by the Linux Foundation, as the next version of Delta Sharing; it adds support for Iceberg REST catalog clients and for sharing AI assets. Catalog-based sharing. The Iceberg REST catalog, with credential vending, already does most of this: a recipient's engine is given a catalog identity limited to certain tables, and receives storage credentials scoped to them. Any Iceberg-compatible engine can read. Platform-native sharing. Cloud warehouses and lakehouse platforms offer sharing between accounts on the same platform, and marketplaces for publishing datasets. These are easy for recipients on that platform, but tie both sides to it. ``` sequenceDiagram participant R as Recipient engine participant S as Sharing server or catalog participant O as Object storage R->>S: List shared tables (recipient token) S-->>R: supplier_sales R->>S: Read supplier_sales S->>S: Check share, apply partition filter S-->>R: File list with short-lived URLs or credentials R->>O: Read only those files ``` A share is defined by the provider: which tables, which partitions or rows, which columns, for which recipient. Row restrictions are often implemented by sharing a view or a dedicated table per recipient, or by sharing only certain partitions, because the recipient's engine is outside the provider's control and cannot be trusted to apply filters itself. Data that the recipient must not see should not be in the files they can read. Sharing differs from exporting in what the provider keeps. With a share, the provider controls access, can revoke it, sees access logs and updates the data in place. With an export, the copy is out of the provider's hands from the moment it is sent. Exports still have their place, for recipients without any compatible tools, or for formal deliveries that must be frozen. A shared table is a published interface. Recipients build on its structure and meaning, so it needs a contract, an owner and change notice, like any data product. ## Key terms - Share A named set of tables or views made available to a recipient. - Provider The party that owns and shares the data. - Recipient The party that reads shared data with its own tools. - Pre-signed URL A time-limited link that grants read access to one object. - Sharing protocol An open API for discovering and reading shared tables. - Export A copy of data sent to someone, outside the provider's control. ## Example The shop shares each supplier's sales with that supplier (suppliers sell stock to the shop), so suppliers can plan stock. The shop builds shop.supplier\_sales, partitioned by supplier\_id, with daily sales per product and no customer data. For supplier sp-12 it creates a share containing only partition supplier\_id = 'sp-12', and issues the supplier a recipient credential. The supplier's analysts connect their own notebook, using a sharing protocol client: ``` import delta_sharing profile = "shop-share.json" # endpoint and recipient token, sent by the shop # share.schema.table: share and schema names are chosen by the provider when creating Optional # the share; they need not match shop.supplier_sales Optional df = delta_sharing.load_as_pandas(f"{profile}#supplier_sp12.sales.supplier_sales") ``` They always see current data, never other suppliers' sales, and when the contract with sp-12 ends the shop revokes the token; no new file lists are issued, and URLs already handed out expire within their short lifetime. ## Pitfalls - Sharing tables with more than the recipient may see. Their engine is outside your control; share only what they are allowed to read. - Long-lived credentials for recipients. Use short-lived tokens and review shares regularly. - Shares without a contract. Recipients break when the table changes. - Assuming sharing avoids residency rules. A recipient reading from another country is still a transfer. - Cost surprises. Recipients reading large data across regions or clouds can create transfer charges for the provider. ## Learn more - [Delta Sharing protocol]() - [Databricks, OpenSharing announcement (June 2026)]() ## Related [Multi-tenancy]() [Residency and regions]() [Data contracts]() [Data products and data mesh]()