Data Sharing and Collaboration
What candidates must know
A share is a named, account-level object that grants read-only access to databases, schemas, tables, views and secure UDFs to other accounts or reader accounts. The provider flow is CREATE SHARE, GRANT USAGE ON DATABASE, GRANT SELECT ON <object>, then ALTER SHARE ... ADD ACCOUNTS; the consumer runs CREATE DATABASE ... FROM SHARE. Sharing is zero-copy: no data is duplicated, the provider pays storage, and the consumer pays compute for its own warehouse. Know secure views (for row- and column-level filtering without exposing the definition), listings and the Marketplace, reader accounts for clients without a Snowflake account, cross-region replication of shared objects, and how a consumer cannot re-share or modify shared data.
Traps
- A non-secure view shared with a consumer exposes the underlying table definition; use secure views for anything sensitive.
- Consumers cannot grant shared data onward and cannot insert, update or delete it.
- A share cannot be created on a temporary table, and objects must be explicitly granted to the share - database-level grants alone are insufficient.
- Consumers cannot run Time Travel on shared objects; retention belongs to the provider.
- Reader accounts are billed to the provider, so credit consumption is a governance concern.
Rule of thumb
Share through secure views, never raw tables, so you can change underlying schema without breaking consumers and can enforce row-level filters.
Worked example
Provider grants SELECT on a secure view SALES_V filtered by region to the share. Consumer creates a database from the share and queries it with its own warehouse. If the provider drops the view, the consumer's query fails immediately - shares are live references, not snapshots.