Delta Sharing and Snowflake Secure Data Sharing both give another organisation read access to tables without sending it a copy, which is what data sharing means on a cloud platform. They differ in kind. Delta Sharing is an open protocol that any client can implement, and Secure Data Sharing is a feature that works between Snowflake accounts. This comparison takes the two questions on which a provider's licence and a recipient's architecture both turn: who can be a recipient, and what happens when access is withdrawn. It ends with the statements each side runs.
A word on the name. Delta Sharing is the name the protocol was published under, and its specification still carries it. In June 2026 Databricks announced OpenSharing as the next evolution of the protocol, the project site describes OpenSharing as formerly Delta Sharing, and Databricks's documentation now uses the new name. This piece says Delta Sharing for the protocol and OpenSharing where it reports what Databricks documents.
Fokals is delivered direct, by REST API and as bulk files, which you load into Snowflake or Databricks with the platform's own loader. The loaded tables are your own, and a later section covers sharing them onward under a licence that grants redistribution.
An open protocol and a platform feature
The Delta Sharing specification defines a REST protocol. A share is a logical grouping of schemas and tables, a recipient is a principal that holds a bearer token, and a sharing server is any server that implements the protocol. The server does not send the table data itself. It returns pre-signed URLs for individual data files, or temporary cloud credentials for a table's directory, and the client reads from cloud storage. Because the protocol is public, the client can be pandas, Apache Spark, Power BI or another tool with a connector, and the server can be the one built into Databricks or one a provider runs itself.
Secure Data Sharing is built into Snowflake. A share is a named Snowflake object: the provider grants it privileges on a database and on objects inside it, and adds the accounts that may consume it. Snowflake's documentation says that sharing copies and transfers no data between accounts: it works through Snowflake's services layer and metadata store, and the consumer creates a read-only database from the share. The same page says data sharing is only supported between Snowflake accounts.
| Delta Sharing (OpenSharing) | Snowflake Secure Data Sharing | |
|---|---|---|
| What it is | An open REST protocol, with a server built into Databricks | A feature of the Snowflake platform |
| Who can provide | Anyone who runs a sharing server; on Databricks, a workspace enabled for Unity Catalog | A Snowflake account |
| Who can receive | Any client that implements the protocol | A Snowflake account, or a reader account the provider creates |
| What the recipient holds | A credential file with a bearer token, a federated identity, or on Databricks a metastore identifier | Its account, named in the share; a role with the IMPORT SHARE privilege creates the database |
| Where the data is read | In the provider's cloud storage, through URLs or temporary credentials | In the provider's Snowflake account, with no copy |
| Who pays to query | The recipient's own engine does the reading; cross-region egress can fall on the provider | The consumer pays for compute; in a reader account the provider pays |
| How access is withdrawn | Revoke the grant, expire or rotate the token, drop the recipient | Remove the account, revoke a privilege, drop the share |
Who can be a recipient
A recipient on the provider's own platform. Databricks calls this Databricks-to-Databricks sharing. The provider creates a recipient from the sharing identifier of the recipient's Unity Catalog metastore, a string of cloud, region and UUID, and the recipient needs no credential file. Databricks lists in a support matrix which clouds and regulated environments can share with each other, and a share for such a recipient can also hold notebook files, views, volumes and models as well as tables, as its overview describes. In Snowflake the equivalent is a direct share, which the documentation limits to accounts in the provider's region. To reach another region or cloud a provider uses a listing with Cross-Cloud Auto-fulfillment, or replication.
A recipient with no account on the provider's platform. This is the case an open protocol is designed for. In Databricks's open sharing the provider issues a credential file that includes a bearer token, or sets up OpenID Connect federation so that the recipient's own identity provider vouches for it, and the recipient reads with a connector. Snowflake's answer is the reader account. The provider creates, owns and manages it and pays for the credits its users consume. It can consume data only from that provider and cannot load or modify data, and because it has no agreement with Snowflake, support runs through the provider.
A recipient on the other platform. The two meet. Snowflake documents a catalog integration for Delta Sharing: a Snowflake account authenticates to a Delta Sharing server with a bearer token, OpenID Connect or OAuth and queries the shared Delta tables through a catalog-linked database, read-only. In the other direction, Snowflake's page on Open Data Sharing describes sharing Apache Iceberg tables with consumers outside Snowflake through Iceberg REST Catalog APIs.
What the recipient holds
The mechanisms differ most in what proves the recipient's right to read, and a licence should name it.
In open sharing it is a secret. The recipient holds a credential file that includes a bearer token, and a bearer token works for whoever possesses it. Databricks's page on recipient tokens sets the controls: a token is valid for at most one year, a recipient has at most two at a time, an active one and a rotated one, and the provider can restrict a recipient to listed IP addresses. One dated notice on that page deserves a diary entry. Open sharing tokens issued before 8 December 2025 whose expiry falls after 8 December 2026, or that have none, will expire automatically on 8 December 2026.
In Snowflake, and in Databricks-to-Databricks sharing, it is an identity: the provider names an account or a metastore, and people gain access through roles inside the recipient's own platform. In Snowflake the role that creates the database from a share needs the IMPORT SHARE privilege, and a share can be consumed once per account.
Revocation: what stops, and when
Snowflake's page on managing shares states the timing. An object removed from a share is instantly unavailable to consumers. When an account is removed, the database it created from the share is invalidated instantly and every query on it stops working. Adding the account back does not restore that database: the consumer must create a new one. Dropping a share invalidates all databases created from it, and a share recreated under the same name is a new share. The page advises providers to weigh the effect on consumers first, and notes that removing single objects can be undone without any work on the consumer's side.
On Databricks the provider has four levers, set out on its pages for granting access, managing recipients and managing shares. It can revoke the recipient's SELECT on the share. It can rotate a token and set the old one to expire at once. It can drop the recipient, which ends access to every share and invalidates its tokens. It can drop the share. A token also ends by itself when it expires.
| What you want | Delta Sharing on Databricks | Snowflake |
|---|---|---|
| Withdraw one table | Remove the table from the share | Revoke the privilege from the share |
| Withdraw one recipient | Revoke SELECT on the share, or drop the recipient | Remove the account from the share |
| Contain a leaked credential | Rotate the token, expiring the old one at once | Remove the account from the share |
| Withdraw everyone | Drop the share | Drop the share |
| Undo a mistake | Grant again | Add the account again; the consumer creates a new database |
Two limits remain. In the Delta Sharing protocol, files are fetched with URLs or cloud credentials that the server issued for a request. Databricks describes the URLs as short-lived, so ask a provider how long they last if minutes matter. And on both sides revocation does not reach a copy. Databricks tells recipients they can read and make copies of shared data. A Snowflake consumer cannot clone an imported database or use Time Travel on it, but it can write query results to its own tables: Snowflake's page on paying for listings lists CREATE TABLE AS SELECT on paid data among the statements that are billed. What happens to copies when a licence ends is therefore a term of the licence.
The statements, side by side
Acme Robotics is illustrative, as are the object names.
-- Snowflake, provider: one table to one account
create share partner_share;
grant usage on database acme to share partner_share;
grant usage on schema acme.reports to share partner_share;
grant select on table acme.reports.fleet_summary to share partner_share;
alter share partner_share add accounts = partner_org.partner_account;
-- Snowflake, consumer
create database acme_shared from share acme_account.partner_share;
-- Snowflake, withdrawal: the consumer's database stops working at once
alter share partner_share remove accounts = partner_org.partner_account;-- Databricks, provider: one table to one open recipient
CREATE SHARE IF NOT EXISTS partner_share;
ALTER SHARE partner_share ADD TABLE acme.reports.fleet_summary;
CREATE RECIPIENT IF NOT EXISTS partner_one;
GRANT SELECT ON SHARE partner_share TO RECIPIENT partner_one;
-- Databricks, withdrawal
REVOKE SELECT ON SHARE partner_share FROM RECIPIENT partner_one;The open recipient needs no platform at all:
import delta_sharing
# <profile-path> is the credential file the provider sent
table = "<profile-path>#partner_share.reports.fleet_summary"
df = delta_sharing.load_as_pandas(table)Sharing tables that hold licensed data
Either mechanism makes onward sharing a matter of a few statements, and neither knows what your licences allow. If a table you share contains data you licensed, check the agreement first. Fokals is licensed by written agreement for internal use, embedding in a product or redistribution, and a share to another organisation passes the data on, so which of those uses your agreement grants decides whether you may share. Under a redistribution licence, a share you create over the tables you loaded passes Fokals firmographic, technographic, hiring and intent data to your own customers, and because daily and weekly datasets are written once and never revised, the closed periods your recipients read stay as they were delivered. The guide to redistributing company data under licence lists what to settle, and the delivery page describes the API and files that the data arrives in.
Choosing by use
- Provider and recipients are all on Snowflake. Secure Data Sharing needs no pipeline, and a listing extends it across regions.
- Recipients are on many platforms, or on none. Delta Sharing reaches a notebook, a BI tool or another warehouse with one share.
- The recipient has no platform and you will pay for its queries. A Snowflake reader account does that by design.
- Withdrawal has to be fast and evidenced. Both document revocation on demand. Snowflake states that the consumer's database is invalidated instantly. Where access rests on a bearer token, write rotation and expiry into the contract as well.
- The data is delivered direct. Load it with the platform's own loader. Either mechanism then shares the loaded tables as it shares any table of your own, within the uses your licence grants.
The platform guides to Delta Sharing and Snowflake Secure Data Sharing take each mechanism clause by clause, and Snowflake vs Databricks compares the platforms around them.
Frequently asked questions
Is Delta Sharing the same as OpenSharing?
OpenSharing is the next evolution of Delta Sharing. Databricks announced it in June 2026, the OpenSharing project site describes it as formerly Delta Sharing, and the project's repository says it is a superset of Delta Sharing and that existing Delta Sharing clients are compatible with it. Databricks's documentation now uses the name OpenSharing. The original specification is still published on GitHub as the Delta Sharing protocol, and the Python client is still installed as delta-sharing.
Can Snowflake read a Delta Sharing share?
Yes. Snowflake documents a catalog integration for Delta Sharing. The Snowflake account authenticates to the provider's sharing server with a bearer token, OpenID Connect or OAuth, and a catalog-linked database then exposes the shared tables for queries. Snowflake's page says the tables are read-only in Snowflake and that the integration supports Delta tables only.
Do you need a Snowflake account to receive a Snowflake share?
Secure Data Sharing works only between Snowflake accounts. For a consumer that is not a Snowflake customer, the provider can create a reader account, which it owns, manages and pays for. Users of a reader account can query what that one provider shares, but cannot load or modify data. Snowflake also describes sharing Apache Iceberg tables with outside consumers through Iceberg REST Catalog APIs.
What happens when a provider revokes a share?
In Snowflake, removing a consumer account from a share instantly invalidates the database that account created from it, and adding the account back requires a new database. On Databricks, revoking a recipient's access, dropping the recipient or expiring its token ends further reads through the sharing server. In both cases, data the recipient already copied into its own tables or files stays where it is.
Who pays for queries on shared data?
In Snowflake the consumer pays for the compute its queries use, and shared data takes up no storage in the consumer's account. In a reader account the provider pays for the compute as well. With Delta Sharing the recipient's own engine reads the files, and Databricks notes that a provider's cloud vendor may charge egress when data is shared across regions or clouds.
Can I share tables that hold Fokals data with another organisation?
Yes, where your agreement grants redistribution. Fokals is licensed by written agreement for internal use, embedding in a product or redistribution, and is delivered direct, by REST API and as bulk files, which you load into your own Snowflake account or Databricks workspace. The loaded tables are your own copy under the licence. A share to another organisation passes the data on, so the redistribution right in your agreement is what authorises it, and either mechanism then carries it out in a few statements.
The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.
What this page says about the products it names was checked against their public documentation on 4 October 2026. Product and company names are trademarks of their owners. Fokals is not affiliated with them or endorsed by them.