Secure Data Sharing
Secure Data Sharing is Snowflake’s feature for giving other Snowflake accounts access to data without copying it to them. A provider account grants access to selected objects; consumer accounts query those objects directly, reading the provider’s single copy. It is one concrete implementation of a broader idea — sharing by granting access rather than by delivering extracts.
Product details below were checked against Snowflake’s documentation in September 2026 and may change.
How it works
The provider creates a share, a named object that encapsulates what is being shared, and specifies which accounts may use it. Shareable objects include databases, tables, dynamic tables, external tables, Apache Iceberg tables, views, user-defined functions, and several other object types. Consumers get read-only access to those objects and query them with their own compute.
Snowflake’s documentation states the key properties directly:
- No copy. No actual data is copied or transferred between accounts; sharing happens through Snowflake’s services layer and metadata store.
- Read-only. Consumers cannot modify or delete shared objects.
- Consumer pays compute only. Shared data takes up no storage in the consumer account; the only consumer charges are for the virtual warehouses used to query it.
- Live. New objects added to a share, and updates to existing shared objects, become available to consumers immediately.
Why it matters
| Extract and deliver | In-place sharing (same region) | |
|---|---|---|
| Copies | One per consumer, plus the pipeline’s intermediates | One, owned by the provider |
| Freshness | As old as the last delivery | Current, because there is only one copy |
| Storage cost | Paid on both sides | Paid by the provider |
| Revoking access | The consumer keeps whatever was delivered | Access is controlled by the provider’s grant rather than by what was delivered |
The freshness row changes how teams work: a consumer’s view cannot drift from the source the way an extract does, and there is no delivery pipeline to monitor. Governance shifts accordingly. Because sharing is a grant, what a consumer can see is defined by what the share contains — a view can be shared instead of the table beneath it — so the share’s definition is where review belongs.
Where the limits are
- Regions and clouds. The no-copy description applies within a region. Snowflake documents that sharing across regions or cloud platforms uses its replication functionality: the provider creates a copy per region — one per region, not one per consumer — and refreshes it manually or on a schedule. A second copy, replication cost, and a refresh lag return. A schedule sets how often a refresh starts, not how current the data is; Snowflake’s schedule parameter skips a run if the previous one has not finished, so freshness has to be measured rather than read off the schedule.
- One platform. The mechanism works inside Snowflake. Across different engines, the open equivalent is an open table format read through a shared catalog, which trades the managed experience for engine independence.
- Changes still break consumers. Sharing removes copies, not coupling. A column the provider renames or drops disappears for every consumer at once, so shared objects need the same change discipline as any published interface.
When to share in place, when to use an open format, and when an extract is still the right answer is worked through in Enterprise Scale: One Platform, Workloads That Disagree.
References: Snowflake Documentation, About Secure Data Sharing; Snowflake Documentation, Share data securely across regions and cloud platforms.
Discover more from Insightful Data Lab
Subscribe to get the latest posts sent to your email.