Sharing and consuming data through shares, views, listings, and Streamlit apps
Snowflake Secure Data Sharing lets providers give consumers live, read-only access to database objects without copying or moving data, using a share object that bundles privileges and consumer accounts. Consumers query shared data using their own compute, and Snowflake extends this model through Reader Accounts and Marketplace listings for broader distribution. Understanding how shares, replication, and Reader Accounts interact is central to designing consumption solutions.
1 · Learn the must-know
- A share is a named Snowflake object that packages database/schema-level privileges on specific tables, secure views, or secure UDFs along with a list of consumer accounts; it never copies data.
- Consumers who already have a Snowflake account create a database directly from the inbound share; organizations without Snowflake can instead be given a provider-managed Reader Account for read-only querying.
- Because shared objects reference the provider's storage, the provider always retains storage costs while consumers incur only their own compute costs when querying shared data.
- Sharing across regions or cloud platforms requires the provider to replicate the database to the consumer's region/cloud (or use auto-fulfillment) since shares only work within the same region and cloud platform by default.
- The Snowflake Marketplace (built on Secure Data Sharing) lets providers publish listings for public or private discovery, supporting both free and monetized data products, while still relying on the same underlying share mechanics.
- Only secure views, secure UDFs, and tables (not standard views, temporary/transient tables, or session-specific objects) can be exposed through a share to protect underlying logic and ensure consistent read-only access.
3 · Keep going
Ready for more? Take a weighted mock or try free practice questions.