Secure data sharing lets one Snowflake account give another account read access to live data without copying or moving it. The consumer queries the provider's storage directly, through metadata pointers.
How it works
The provider creates a share, adds objects to it (databases, schemas, secure views, tables), and grants it to the consumer account:
CREATE SHARE sales_share; GRANT USAGE ON DATABASE sales TO SHARE sales_share; GRANT SELECT ON TABLE sales.public.orders TO SHARE sales_share; ALTER SHARE sales_share ADD ACCOUNTS = partner_account;
The consumer then creates a read-only database from the share, and queries it like any other.
CREATE DATABASE partner_sales FROM SHARE provider_account.sales_share;
Properties worth noting
- No data movement. There is no ETL, no files, no sync lag. When the provider updates the table, the consumer sees the change on the next query.
- The consumer pays for the compute of their own queries, using their own warehouse. The provider pays for storage.
- The shared database is read-only for the consumer. They can create their own tables from it, but they cannot change the shared data.
- The provider can revoke access at any time.
Consumers without Snowflake
A provider can create a reader account, a managed account that lets a partner without Snowflake query the shared data. The provider pays for the reader account's compute.
Regions and clouds
Sharing directly works within the same region and cloud. For another region or cloud, the data has to be replicated there first, which does involve a copy and storage cost.
Marketplace
Providers can list datasets publicly or privately, and consumers can get them with a few clicks.
A good interview example: a retailer shares daily sell-through data with a supplier, as a secure view limited to that supplier's products. No files are emailed, and the supplier always sees the latest numbers.