Secure data sharing basics in Snowflake - Deep Dive

Overview - Secure data sharing basics

What is it?

Secure data sharing is a way to safely give access to data stored in Snowflake without copying or moving it. It allows one Snowflake account to share specific data with another account instantly and securely. This sharing happens without creating duplicate data, keeping the original data safe and consistent. It is designed to make collaboration easy while protecting sensitive information.

Why it matters

Without secure data sharing, organizations would have to copy data to share it, causing delays, extra storage costs, and risks of outdated or leaked data. Secure sharing solves these problems by providing real-time access to data without duplication. This means faster decisions, lower costs, and stronger data protection, which are critical in today’s fast-paced and privacy-focused world.

Where it fits

Before learning secure data sharing, you should understand basic cloud data storage and Snowflake’s data warehouse concepts. After mastering secure data sharing, you can explore advanced topics like data governance, access control policies, and cross-cloud data integration.

Mental Model

Core Idea

Secure data sharing lets you give others safe, real-time access to your data without copying it.

Think of it like...

It’s like lending a book from your personal library to a friend without giving them the book itself; they can read it anytime but the book stays with you.

┌───────────────┐       ┌───────────────┐
│ Data Provider │──────▶│ Data Consumer │
│ (Owner)      │       │ (Reader)      │
└───────────────┘       └───────────────┘
       │                        ▲
       │ Secure Share Link      │
       └────────────────────────┘

Build-Up - 6 Steps

1

Foundation

What is Data Sharing in Snowflake

Concept: Introduction to the basic idea of sharing data between Snowflake accounts.

Snowflake allows one account to share data with another without copying it. This is done by creating a 'share' object that lists the data to share. The other account can then access this data directly from the provider's storage.

Result

You understand that data sharing is about access, not duplication.

Knowing that sharing does not copy data helps you appreciate its efficiency and security.

2

Foundation

Components of Secure Data Sharing

Concept: Learn the key parts involved in Snowflake data sharing.

The main parts are: the provider account (owns data), the share object (defines what data is shared), and the consumer account (accesses shared data). Shares include databases, schemas, and tables.

Result

You can identify who shares, what is shared, and who receives the data.

Understanding these roles clarifies how Snowflake controls and tracks shared data.

3

Intermediate

How to Create and Use a Share

🤔Before reading on: do you think creating a share copies data or just references it? Commit to your answer.

Concept: Learn the steps to create a share and grant access.

To share data, the provider creates a share object, adds database objects to it, and grants usage to the consumer account. The consumer then creates a database from the share to query the data.

Result

You can set up a share and access shared data without copying it.

Knowing the exact steps prevents common mistakes like missing permissions or incorrect object inclusion.

4

Intermediate

Access Control and Security Features

🤔Before reading on: do you think consumers can modify shared data? Commit to your answer.

Concept: Understand how Snowflake enforces security on shared data.

Consumers get read-only access to shared data. They cannot change or delete it. Providers control what data is shared and can revoke access anytime. Shares do not expose credentials or underlying storage details.

Result

You know that data sharing is secure and controlled by the provider.

Understanding read-only access protects data integrity and builds trust between parties.

5

Advanced

Cross-Cloud and Cross-Region Sharing

🤔Before reading on: do you think Snowflake shares data only within the same cloud region? Commit to your answer.

Concept: Explore how Snowflake supports sharing across different cloud providers and regions.

Snowflake allows sharing data across AWS, Azure, and GCP clouds and across regions. This is done without moving data physically, using Snowflake’s global network. It enables global collaboration with low latency.

Result

You can design data sharing strategies that span clouds and geographies.

Knowing cross-cloud sharing expands your ability to build flexible, global data solutions.

6

Expert

Performance and Cost Implications of Sharing

🤔Before reading on: do you think sharing data increases storage costs for the consumer? Commit to your answer.

Concept: Understand how sharing affects performance and billing.

Shared data does not increase storage costs for consumers since data is not copied. However, consumers pay for compute when querying shared data. Providers monitor usage to manage costs and performance impact.

Result

You can optimize sharing setups to balance cost and performance.

Knowing cost and performance details helps avoid unexpected bills and slow queries in production.

Under the Hood

Snowflake stores data in a central cloud storage layer separated from compute. When a share is created, Snowflake creates metadata pointers to the shared data objects. Consumers access data through these pointers, which Snowflake resolves in real-time without duplicating data. Access control is enforced by Snowflake’s security layer, ensuring read-only access and audit logging.

Why designed this way?

Snowflake designed sharing to avoid data duplication to save storage costs and ensure data consistency. Separating storage and compute allows multiple consumers to query the same data simultaneously without interference. This design supports scalability, security, and real-time collaboration.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Provider      │       │ Snowflake     │       │ Consumer      │
│ Account       │──────▶│ Metadata &    │──────▶│ Account       │
│ (Data Owner)  │       │ Storage Layer │       │ (Data Reader) │
└───────────────┘       └───────────────┘       └───────────────┘
       │                      ▲   ▲                      │
       │                      │   │                      │
       └──────────────────────┘   └──────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does sharing data in Snowflake create a copy of the data? Commit to yes or no.

Common Belief: Sharing data means copying it to the consumer’s account.

Reality: Sharing only creates metadata references; data is not copied or moved.

Why it matters: Believing data is copied leads to unnecessary storage costs and confusion about data freshness.

Quick: Can consumers modify shared data? Commit to yes or no.

Common Belief: Consumers can update or delete shared data.

Reality: Consumers have read-only access and cannot change shared data.

Why it matters: Thinking consumers can modify data risks data integrity and trust between parties.

Quick: Is data sharing limited to the same cloud provider? Commit to yes or no.

Common Belief: Data sharing only works within the same cloud provider and region.

Reality: Snowflake supports cross-cloud and cross-region sharing seamlessly.

Why it matters: Underestimating sharing scope limits design of global data collaboration.

Quick: Does sharing data increase storage costs for the consumer? Commit to yes or no.

Common Belief: Consumers pay storage costs for shared data.

Reality: Consumers only pay for compute when querying; storage remains with the provider.

Why it matters: Misunderstanding billing can cause budgeting errors and reluctance to share.

Expert Zone

1

Shares can include secure views to mask sensitive columns, enabling fine-grained data control.

2

Providers can revoke or modify shares instantly, allowing dynamic control over data access.

3

Snowflake’s data sharing metadata is eventually consistent, so small delays may occur before consumers see updates.

When NOT to use

Avoid secure data sharing when consumers need write access or when data must be transformed before sharing. In such cases, consider data replication or ETL pipelines.

Production Patterns

Enterprises use secure data sharing for partner collaboration, real-time analytics across business units, and monetizing data by sharing with customers without losing control.

Connections

Access Control Lists (ACLs)

Builds-on

Understanding ACLs helps grasp how Snowflake controls who can see shared data and what actions they can perform.

Content Delivery Networks (CDNs)

Similar pattern

Like CDNs deliver content without copying it everywhere, Snowflake shares data by referencing it without duplication, optimizing speed and cost.

Library Lending Systems

Analogous system

Knowing how libraries lend books without giving ownership clarifies the concept of read-only, controlled access in data sharing.

Common Pitfalls

#1 Sharing data without granting usage privileges.

Wrong approach:

CREATE SHARE my_share;
ALTER SHARE my_share ADD TABLE sales_data;
-- Missing: GRANT USAGE ON DATABASE and SCHEMA to share

Correct approach:

CREATE SHARE my_share;
ALTER SHARE my_share ADD TABLE sales_data;
GRANT USAGE ON DATABASE sales_db TO SHARE my_share;
GRANT USAGE ON SCHEMA sales_db.public TO SHARE my_share;

Root cause:

Not understanding that shares require explicit usage grants on database and schema to be accessible.

#2 Assuming consumers can write to shared data.

Wrong approach:

Consumer runs: INSERT INTO shared_db.sales_data VALUES (...);

Correct approach:

-- Consumers cannot modify shared data; they must query only:
SELECT * FROM shared_db.sales_data;

Root cause:

Misunderstanding that shared data is read-only for consumers.

#3 Sharing data across accounts without verifying cloud region compatibility.

Wrong approach:

Provider in AWS us-east-1 shares data with consumer in Azure west-europe without setup.

Correct approach:

Use Snowflake’s cross-cloud sharing features that handle region and cloud differences transparently.

Root cause:

Lack of awareness of cross-cloud sharing capabilities and requirements.

Key Takeaways

Secure data sharing in Snowflake provides real-time, read-only access to data without copying it.

It relies on share objects that define what data is shared and who can access it.

Consumers cannot modify shared data, ensuring data integrity and security.

Snowflake supports sharing across different cloud providers and regions seamlessly.

Understanding permissions and billing implications is essential to use sharing effectively and avoid surprises.

Practice

1. What is the main benefit of using secure data sharing in Snowflake?

easy

A. Encrypt data before sharing it manually

B. Share live data without making copies

C. Create multiple copies of data for each user

D. Send data files via email securely

Solution

1. Step 1: Understand secure data sharing purpose

   Secure data sharing allows sharing data directly without duplication.

2. Step 2: Compare options

   Options A, B, and D involve copying or manual steps, which are not the main benefit.

3. Final Answer:

   Share live data without making copies -> Option B

4. Quick Check:

   Secure sharing = live data, no copies [OK]

Hint: Secure sharing means no data copies needed [OK]

Common Mistakes:

• Thinking data is copied to recipients
• Confusing sharing with encryption only
• Assuming manual file transfer is secure sharing

2. Which Snowflake object do you create first to start sharing data securely?

easy

A. Share

B. Role

C. Warehouse

D. Database

Solution

1. Step 1: Identify the object for sharing

   In Snowflake, a Share object is created to define what data to share.

2. Step 2: Eliminate other options

   Databases hold data, warehouses process queries, roles manage permissions but do not start sharing.

3. Final Answer:

   Share -> Option A

4. Quick Check:

   Create a Share to share data [OK]

Hint: Start sharing by creating a Share object [OK]

Common Mistakes:

• Trying to share by creating a database
• Confusing warehouse with sharing object
• Assuming roles start sharing

3. Given this SQL snippet, what does it do?

CREATE SHARE my_share;
GRANT SELECT ON DATABASE sales_db TO SHARE my_share;
ALTER SHARE my_share ADD ACCOUNTS = ('account_123');

medium

A. Creates a share, grants access to sales_db, and shares with account_123

B. Creates a database named my_share and grants access to account_123

C. Adds a new database to sales_db and shares it with account_123

D. Creates a warehouse named my_share and assigns it to account_123

Solution

1. Step 1: Analyze each command

   CREATE SHARE my_share; creates a share object named my_share.
   GRANT SELECT ON DATABASE sales_db TO SHARE my_share; grants read access on sales_db to the share.
   ALTER SHARE my_share ADD ACCOUNTS = ('account_123'); adds account_123 as a recipient.

2. Step 2: Understand the overall effect

   This sequence shares sales_db data with account_123 via my_share.

3. Final Answer:

   Creates a share, grants access to sales_db, and shares with account_123 -> Option A

4. Quick Check:

   Share + grant + add account = share data [OK]

Hint: Look for CREATE SHARE then GRANT and ADD ACCOUNTS [OK]

Common Mistakes:

• Confusing share with database creation
• Thinking ALTER SHARE adds data, not accounts
• Mixing warehouse and share concepts

4. You run this command but get an error:

ALTER SHARE my_share ADD ACCOUNTS = ('account_123', 'account_123');

What is the likely cause?

medium

A. Account names must be numeric

B. Missing SELECT privilege on the share

C. Share name is invalid

D. Duplicate account names in the list

Solution

1. Step 1: Check the command syntax and parameters

   The command tries to add two accounts with the same name 'account_123' to the share.

2. Step 2: Identify the error cause

   Duplicate account names in the ADD ACCOUNTS list cause an error because each account must be unique.

3. Final Answer:

   Duplicate account names in the list -> Option D

4. Quick Check:

   Duplicate accounts cause errors [OK]

Hint: Avoid duplicate accounts in ADD ACCOUNTS list [OK]

Common Mistakes:

• Assuming share name is invalid without checking
• Thinking privileges cause this error
• Believing account names must be numbers

5. You want to share only specific tables from your database securely. Which approach should you use?

hard

A. Grant SELECT on the entire database to the share

B. Grant SELECT on specific schemas to the share

C. Grant SELECT on specific tables to the share

D. Create a new database with only those tables and share it

Solution

1. Step 1: Understand granularity of sharing

   Snowflake allows granting privileges at database, schema, or table level to shares.

2. Step 2: Choose the most precise option

   Granting SELECT on specific tables limits sharing to only those tables, which fits the requirement.

3. Step 3: Evaluate other options

   Granting on entire database or schema shares more than needed; creating a new database is extra work and less flexible.

4. Final Answer:

   Grant SELECT on specific tables to the share -> Option C

5. Quick Check:

   Grant on tables = share specific data [OK]

Hint: Grant on tables to share only those tables [OK]

Common Mistakes:

• Granting on database shares too much data
• Assuming schema-level grant is always best
• Creating new databases unnecessarily