How Secure Data Sharing Works
Secure Data Sharing lets a Snowflake account (the provider) grant another Snowflake account (the consumer) live, read-only access to selected databases, schemas, tables, or views without physically copying any data. Under the hood, a SHARE object bundles grants on specific objects, and the consumer creates a database from that share that reads directly from the provider's storage layer, meaning updates on the provider side are visible to the consumer immediately, with zero ETL pipeline and zero data duplication.
Cricket analogy: It's like a stadium's official live scoring feed being piped directly into a broadcaster's graphics system, so both show the exact same live score with no lag or re-entry.
Provider and Consumer Roles
On the provider side, a role with sufficient privileges creates a SHARE, grants USAGE on a database and its schemas, and grants SELECT on specific tables or views to that share, then adds one or more consumer account identifiers to it. On the consumer side, a user with the IMPORT SHARE privilege runs CREATE DATABASE ... FROM SHARE to materialize the shared objects as a read-only database in their own account, which can then be queried like any other database, joined against local tables, and governed with the consumer's own role-based access control on top of what the provider exposed.
Cricket analogy: The provider is like a host broadcaster granting a foreign network rights to relay its live feed, while the consumer network decides how to package and present that feed to its own local viewers.
-- Provider side: create and populate a share
CREATE SHARE sales_share;
GRANT USAGE ON DATABASE sales_db TO SHARE sales_share;
GRANT USAGE ON SCHEMA sales_db.public TO SHARE sales_share;
GRANT SELECT ON TABLE sales_db.public.orders TO SHARE sales_share;
ALTER SHARE sales_share ADD ACCOUNTS = xy12345.partner_account;
-- Consumer side: materialize the shared database
CREATE DATABASE sales_shared_db FROM SHARE xy12345.sales_share;
-- Consumer queries it like any normal database
SELECT region, SUM(amount)
FROM sales_shared_db.public.orders
GROUP BY region;Reader Accounts and the Snowflake Marketplace
For consumers who don't have their own Snowflake account, a provider can create a Reader Account, a lightweight Snowflake account fully managed and billed under the provider, which can consume a share without the recipient needing to become a Snowflake customer. At larger scale, providers can list their shares publicly or privately on the Snowflake Marketplace, where consumers can discover, request, and mount third-party datasets — such as weather, financial, or demographic data — directly as live databases, often evaluating them via free trial listings before committing.
Cricket analogy: A reader account is like a stadium issuing a guest broadcast pass to a smaller local station that doesn't own its own uplink truck, fully sponsored by the host venue.
Because Secure Data Sharing reads directly from the provider's storage, consumers never pay for the storage of shared data — only for the compute (virtual warehouse) they use to query it. This makes it fundamentally cheaper than exporting and re-importing datasets across organizations.
A share only exposes what has been explicitly granted to it — nothing more. If a provider table gets new columns or a new table is added to a shared schema, those aren't automatically visible to the consumer unless the provider explicitly grants access to the new objects on the existing share.
- Secure Data Sharing exposes live, read-only data to another account without physically copying or moving it.
- A SHARE object bundles USAGE and SELECT grants on specific databases, schemas, tables, or views.
- Consumers materialize a share with CREATE DATABASE ... FROM SHARE and query it like any normal database.
- Reader Accounts let providers share data with organizations that don't have their own Snowflake account.
- The Snowflake Marketplace lets providers list shares publicly or privately for broader discovery.
- Consumers pay only for their own compute to query shared data, never for the underlying storage.
- Shares expose only explicitly granted objects; new tables or columns require explicit new grants to appear.
Practice what you learned
1. What fundamentally distinguishes Secure Data Sharing from a traditional ETL export/import between organizations?
2. What SQL statement does a consumer use to turn a received share into a queryable database?
3. What is a Reader Account primarily used for?
4. Who pays for the storage cost of data accessed via a share?
5. If a provider adds a new table to a schema that is already shared, what happens on the consumer side?
Was this page helpful?
You May Also Like
Zero-Copy Cloning
How Snowflake's CLONE command creates instant, storage-free copies of tables, schemas, and databases by referencing existing micro-partitions rather than duplicating data.
Roles and Access Control
How Snowflake's role-based access control model governs who can do what, using hierarchical roles, privilege grants, and secure ownership rather than per-user permissions.
Masking Policies and Row Access Policies
How Snowflake dynamically hides sensitive column values or entire rows from unauthorized roles, enforced consistently at query time across every downstream consumer.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics
ProgrammingPowerShell Study Notes
Programming · 30 topics