Providers — Sharing Data with Consumers¶
This topic describes the tasks associated with data providers creating and configuring shares, sharing them with other accounts so that they can be consumed, and performing ongoing maintenance of the shares.
In this Topic:
- Data Sharing and ESD (Enterprise for Sensitive Data) Accounts
- General Data Sharing Considerations and Usage
- Preparing to Create a Share
- Creating a Share
- Determining Whether Consumers Have Created Databases From Shares
- Maintaining Shares
You must use the ACCOUNTADMIN role to perform all these tasks, except preparing your database and objects to share, which can be performed using any role.
Data Sharing and ESD (Enterprise for Sensitive Data) Accounts¶
If you have an ESD account, please note the following conditions for sharing data with other (i.e. consumer) accounts:
|ESD (HIPAA)||to||ESD (HIPAA)||✔||Both HIPAA accounts should have a signed BAA with each other.|
|ESD (HIPAA)||to||ESD||Snowflake does not allow HIPAA accounts to share data with non-HIPAA accounts, even if the other account is an ESD account.|
|ESD||to||ESD or ESD (HIPAA)||✔||Enabled by default.|
|ESD||to||All other editions||✔||Not enabled by default; please contact Snowflake to enable for your account.|
For all other Snowflake Editions:
- VPS (Virtual Private Snowflake) does not support Data Sharing due to the current limitations against cross-region Data Sharing.
- Enterprise, Premiere, and Standard Editions support Data Sharing with the usual caveats.
For more details, see the next section in this topic.
Snowflake is not responsible for ensuring that HIPAA accounts who engage in Data Sharing have a signed BAA with each other; this is at the discretion of the accounts that are sharing data. Note that failure to have a signed BAA may impact the HIPAA compliance of both accounts, particularly the provider account.
Also, if you have an ESD account, to maintain the expected level of data protection provided by ESD, we strongly recommend considering the following before requesting Snowflake to enable Data Sharing with non-ESD accounts:
- Do not share sensitive data with non-ESD accounts.
- Consider creating a second, non-ESD account where you store less sensitive data and share this data with non-ESD accounts.
- If you are using Tri-Secret Secure with your ESD account and you share data with other accounts, Snowflake treats the data access from these accounts as if the access occurred from within your own account. Specifically, granting access to the consumer account may require Snowflake to access your AWS KMS.
These are only recommendations and are not enforced by Snowflake. The decision to share data is always at the discretion of the data provider and Snowflake does not assume any responsibility for data that is improperly shared.
General Data Sharing Considerations and Usage¶
Note the following important usage details for creating and maintaining shares:
Currently, consumer accounts must be in the same Snowflake Region as your account; i.e. you can only share with other accounts in your Snowflake Region.
Each share contains a single database, and all other objects included in the share must be from this same database. This is particularly important to note for views, which are defined by referencing one or more tables; the view and the referenced tables must all be in the same database.
If any referenced objects (i.e. tables) are in a different database, the referencing object (i.e. view) will fail when a user in a consumer account attempts to query it.
For data security and privacy reasons, only secure views are supported in shares at this time. If a standard view is added to a share, Snowflake returns an error.
Adding accounts to a share immediately makes the share available to consume by the accounts.
New and modified rows in tables in a share (or in tables referenced by a view in a share) are available immediately to all consumers who have created a database from the share. Keep this in mind when updating these tables.
A new object created in a database in a share is not automatically available to consumers.
To make the object available to consumers, you must use the GRANT privilege command to explicitly add the object to the share.
This also applies to objects that have been dropped from a database and then recreated with the same name in the database; the recreated object is treated as a new object and is, therefore, not accessible until the object has been explicitly granted the necessary privileges in the share.