Secure Data Sharing is Snowflake's form of data sharing: one account gives another account read access to selected data without sending a copy. For a licensing team that raises practical questions. Who holds the data, how does access end, can the recipient pass it on, and what can the provider see? This guide answers them from Snowflake's documentation, then sets out what a data licence still has to say, because a share and a licence do different jobs.
What a share is
Snowflake's introduction to Secure Data Sharing defines a share as a named object that holds what is needed to share a database. The provider chooses what goes in: databases, tables, dynamic tables, views and some further objects, such as Cortex Search services. The provider guide says that for views only secure views are accepted, so a provider that wants each consumer to see a different slice builds secure views over its tables.
The consumer creates a database from the share. Nothing is copied: the documentation says sharing runs through Snowflake's services layer and metadata store, shared data takes no storage in the consumer account, the provider keeps paying for storage and the consumer pays for the compute that queries it. The imported database is read-only, and the consumer guide adds that it cannot be cloned, replicated or queried with Time Travel.
A licensing team can check scope without reading any data. SHOW SHARES lists the shares an account can consume, and DESCRIBE SHARE lists the objects a share contains. Compare that list with the schedule of data in the agreement, and repeat it when the provider announces a change, because Snowflake says objects added to a share are available to consumers at once.
show shares;
describe share provider_account.share_name;Three routes: direct share, listing and reader account
Snowflake offers three ways to put a share in front of a recipient, and they differ in reach and in how access ends.
| Route | Receiver | Reach and limits | How access ends |
|---|---|---|---|
| Direct share | A Snowflake account | The provider's region only | The provider removes the account from the share, or drops the share |
| Listing, private or on the Marketplace | A Snowflake account | Other regions and clouds, through auto-fulfilment | The provider removes the consumer from the share. Unpublishing alone leaves existing consumers with access |
| Reader account | A recipient with no Snowflake account, through an account the provider creates and pays for | Read-only: no loading and no DML | The provider drops the account |
A listing adds capabilities to a direct share. Snowflake says to use one to share across regions, publish on the Marketplace, charge for access, attach descriptions and sample queries, or view consumer usage metrics.
A listing also has a Terms of Service field, described in the listing reference as the service agreement a consumer must accept before access. On the Marketplace both sides also accept the Snowflake Provider and Consumer Terms, which Snowflake says set out the rights and obligations between Snowflake and its customers. They are not the data licence. The buyer's side of this is covered in the guide to Snowflake Marketplace for buyers of company data.
Region matters to a licence. Snowflake says a direct share works only with accounts in the same region and points to listings with Cross-Cloud Auto-Fulfillment for other regions, where Snowflake replicates the data product and the provider bears the cost. The data then sits in more than one region, and the agreement should name them.
What ends access, and what does not
A provider ends access to a share by removing the consumer's account or by dropping the share. The provider guide says that removing an account instantly invalidates the database the account created from the share, that dropping a share does the same for every consumer, and that an object removed from a share is unavailable to consumers at once. A reader account is ended with DROP MANAGED ACCOUNT, which the reader account guide says drops the objects in the account and restricts all access immediately.
Listings behave differently, and a licence that assumes one switch will be wrong. Snowflake's removal page says that unpublishing removes a listing from the Marketplace but existing consumers keep access. After a deletion, consumers are notified by email and keep access for a retirement window: exactly 30 days for free and limited trial listings, and one full calendar month for paid listings.
Revocation removes the consumer's access to the provider's objects. It does not tell you what happens to tables, models and reports the consumer built from rows it had already read. Those sit in the consumer's own account, outside the share, so the licence has to say whether they survive the end of the term.
Passing data on, and what the provider can see
Resharing is controlled by the provider. The resharing documentation says a consumer can reshare a listing only when the provider has turned resharing on, and then by building secure views in its own database and sharing those, because imported objects cannot be attached to a share directly. For a direct share, the consumer guide says resharing cannot reach accounts outside the consumer's organisation. These settings are technical controls. Whether a recipient may pass data on is a term of the redistribution licence, and the two should say the same thing.
For listings, Snowflake gives the provider a usage view, LISTING_ACCESS_HISTORY, with a row for each access: the consumer account, the time and the objects touched. Its reference page gives up to two days of latency and 365 days of retention, and says the view does not let a provider obtain private consumer information such as the text of queries. A security team can use that to answer whether the provider can read its queries. A provider can use it to see which accounts are querying which objects.
What a licence must still say
A share is a delivery mechanism, and each stage of its life raises a question the mechanism does not answer. The table follows an illustrative licensee, Acme Robotics, that receives a company dataset through a listing.
| Event | What the share or listing does | What the licence must say |
|---|---|---|
| Acme's analysts query the data | A read-only database appears and Acme pays the compute | That internal use is permitted |
| Acme builds a customer-facing report from it | The share does not tell a report from any other query | Whether embedding in a product is permitted |
| Acme's subsidiary wants access | Works only within the provider's resharing setting | Whether affiliates may use the data |
| The term ends and the provider removes Acme from the share | The database Acme created stops working at once | Whether Acme's tables, reports and models built from the data must be deleted, and by when |
| The provider unpublishes the listing | Existing consumers keep access | Whether the agreement ends access or only the listing |
| The provider adds or removes objects | Acme sees the change at once | How changes are announced, and with how much notice |
Two more terms follow from no single event. Say where the data may be held, given the replication above, and say what usage the provider may see and how it may use that.
Fokals is delivered direct, by REST API and as bulk files in JSON, JSON Lines or CSV. You load the data into your own account with Snowflake's own loader, as the guide to loading company data into Snowflake shows, and from then on it sits in your storage, so the written agreement carries every term in the table. Fokals is licensed by agreement for internal use, embedding in a product or redistribution, as the licensing page describes, and labels and scores are produced under frozen versions, with at least 90 days' notice of a breaking change.
A share suits a provider that needs to withdraw data at once, and a listing adds usage visibility. Loading files into your own account suits a buyer that needs the data to stay in its own account under its own retention, backup and audit rules, because a share leaves the data in the provider's account. The comparison of Delta Sharing and Snowflake Secure Data Sharing sets the Snowflake mechanism beside an open protocol.
Frequently asked questions
What is Snowflake Secure Data Sharing?
It is Snowflake's way of giving another account read access to selected objects without copying data. A provider puts databases, tables, secure views and some other objects into a share and adds consumer accounts, and each consumer creates a read-only database from the share. Snowflake's documentation says nothing is copied or transferred between accounts.
Does the consumer of a Snowflake share get a copy of the data?
Not through the share: the documentation says shared data takes no storage in the consumer account, while the provider pays for storage and the consumer pays for the compute that queries it. When a listing is fulfilled to another region, Snowflake replicates the data product there. Whatever a consumer writes into its own tables is outside the share, so a licence has to address copies and derived data.
Can a Snowflake provider revoke access to shared data?
Yes. Removing an account from a share, or dropping the share, instantly invalidates the databases consumers created from it, and objects removed from a share become unavailable at once. For listings, unpublishing alone leaves existing consumers with access, and a deleted listing has a retirement window of 30 days for free and trial listings or one calendar month for paid ones.
What is a Snowflake reader account?
A reader account is an account that a provider creates for a recipient who is not a Snowflake customer. The provider pays for the compute that the reader account's warehouses use, and users can query the shared data but cannot load data or run DML such as INSERT, UPDATE or DELETE. The provider ends access by dropping the account, which restricts all access immediately.
Can a consumer pass Snowflake shared data to someone else?
Only as far as the provider allows. For a listing, the provider must have turned resharing on, and the consumer then shares secure views it builds, never the imported objects directly. For a direct share, Snowflake's consumer guide says resharing cannot reach accounts outside the consumer's organisation. Neither setting replaces a redistribution term in the licence.
Does Snowflake data sharing replace a data licence?
No. A share is an access mechanism, and a listing adds a Terms of Service field that the consumer accepts. Permitted uses, the handling of copies and derived data, and what happens at the end of the term still have to be agreed between provider and consumer. Fokals is delivered direct, by REST API and as bulk files, so its terms come from a written agreement that covers each of these points.
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.