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.

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. That holds for a consumer with its own account; when a provider creates a reader account for a consumer without one, the compute used there is billed to the provider.
• Live. New objects added to a share, and updates to existing shared objects, become available to consumers immediately.

Why it matters

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. Where a residency obligation applies, that copy is the thing to check, not the original. 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 compatibility discipline — and the same data contract — 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.

Further reading

• Snowflake Documentation, About Secure Data Sharing
• Snowflake Documentation, Share data securely across regions and cloud platforms
• Snowflake Documentation, ALTER REPLICATION GROUP (REPLICATION_SCHEDULE)
• Snowflake Documentation, Manage reader accounts