Creating and managing shares in Snowflake - Visual Walkthrough

Process Flow - Creating and managing shares

Start

↓

Create Share

↓

Add Database Objects to Share

↓

Grant Access to Consumers

↓

Manage Share (Add/Remove Objects)

↓

Monitor Share Usage

↓

End

The flow shows creating a share, adding objects, granting access, managing content, and monitoring usage.

Execution Sample

Snowflake

CREATE SHARE my_share;
GRANT USAGE ON DATABASE my_db TO SHARE my_share;
ALTER SHARE my_share ADD SCHEMA my_db.my_schema;
GRANT SELECT ON TABLE my_db.my_schema.my_table TO SHARE my_share;

This code creates a share, adds a database and schema, and grants select access on a table.

Process Table

Step	Action	Object Affected	Result	Notes
1	CREATE SHARE my_share;	Share: my_share	Share created	Share is empty initially
2	GRANT USAGE ON DATABASE my_db TO SHARE my_share;	Database: my_db	Usage granted to share	Share can now reference database
3	ALTER SHARE my_share ADD SCHEMA my_db.my_schema;	Schema: my_schema	Schema added to share	Objects in schema become shareable
4	GRANT SELECT ON TABLE my_db.my_schema.my_table TO SHARE my_share;	Table: my_table	Select granted to share	Consumers can query this table
5	GRANT SHARE my_share TO ACCOUNT consumer_account;	Consumer Account	Access granted	Consumer can now use the share
6	ALTER SHARE my_share REMOVE SCHEMA my_db.my_schema;	Schema: my_schema	Schema removed from share	Objects no longer shared
7	DROP SHARE my_share;	Share: my_share	Share dropped	Share no longer exists

💡 Share dropped or no longer needed, ending management.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	After Step 7
my_share	undefined	created	created with db usage	created with schema	created with table select	shared with consumer	schema removed	dropped
my_db	exists	exists	usage granted to share	usage granted to share	usage granted to share	usage granted to share	usage granted to share	usage granted to share
consumer_account	no access	no access	no access	no access	no access	access granted	access granted	access revoked

Key Moments - 3 Insights

Why do we need to grant USAGE on the database to the share before adding schemas or tables?

Granting USAGE on the database (see Step 2) allows the share to reference objects inside it. Without this, adding schemas or tables to the share will fail.

What happens if we remove a schema from the share after granting access?

Removing the schema (Step 6) removes all objects inside it from the share, so consumers lose access to those objects even if they had access before.

Does creating a share automatically give access to any consumer accounts?

No, creating a share (Step 1) only creates it. Access must be explicitly granted to consumer accounts (Step 5) to allow usage.

Visual Quiz - 3 Questions

Look at the execution table, what is the state of 'my_share' after Step 3?

A Share created with database usage granted

B Share created with schema added

C Share dropped

D Share created with table select granted

💡 Hint

Check the 'Result' column in Step 3 of the execution table.

At which step does the consumer account gain access to the share?

A Step 5

B Step 4

C Step 2

D Step 6

💡 Hint

Look for 'Access granted' in the 'Result' column.

If we skip granting USAGE on the database to the share, what will happen when adding schemas?

A Schemas will be added successfully

B Consumer accounts get access automatically

C Adding schemas will fail

D Share will be dropped automatically

💡 Hint

Refer to the key moment about granting USAGE before adding schemas.

Concept Snapshot

CREATE SHARE share_name;
GRANT USAGE ON DATABASE db_name TO SHARE share_name;
ALTER SHARE share_name ADD SCHEMA db_name.schema_name;
GRANT SELECT ON TABLE db_name.schema_name.table_name TO SHARE share_name;
GRANT SHARE share_name TO ACCOUNT consumer_account;
Use ALTER SHARE to add or remove objects; DROP SHARE to delete.

Full Transcript

Creating and managing shares in Snowflake involves first creating a share object. Then, you grant usage on the database to the share so it can reference objects inside. Next, you add schemas and grant select privileges on tables to the share. After that, you grant access to consumer accounts so they can use the shared data. You can manage the share by adding or removing schemas and tables as needed. Finally, you can drop the share when it is no longer needed. Each step changes the state of the share and its accessibility.

Practice

1. What is the primary purpose of creating a share in Snowflake?

easy

A. To move data from one database to another

B. To create a backup of your data

C. To share data with other accounts without copying it

D. To encrypt data for security

Solution

1. Step 1: Understand the concept of shares in Snowflake

   Shares allow data to be shared between accounts without duplicating the data itself.

2. Step 2: Identify the main use case of shares

   Sharing data without copying saves storage and ensures data consistency.

3. Final Answer:

   To share data with other accounts without copying it -> Option C

4. Quick Check:

   Shares = Data sharing without copying [OK]

Hint: Shares share data directly, no copying needed [OK]

Common Mistakes:

• Thinking shares create data backups
• Confusing shares with data movement
• Assuming shares encrypt data automatically

2. Which Snowflake command correctly creates a share named my_share?

easy

A. ADD SHARE my_share;

B. MAKE SHARE my_share;

C. NEW SHARE my_share;

D. CREATE SHARE my_share;

Solution

1. Step 1: Recall the syntax for creating shares in Snowflake

   The correct command to create a share is CREATE SHARE <share_name>;.

2. Step 2: Compare options with correct syntax

   Only CREATE SHARE my_share; uses the correct CREATE SHARE syntax.

3. Final Answer:

   CREATE SHARE my_share; -> Option D

4. Quick Check:

   CREATE SHARE = correct command [OK]

Hint: Use CREATE SHARE to start a new share [OK]

Common Mistakes:

• Using MAKE or NEW instead of CREATE
• Forgetting the semicolon at the end
• Confusing ADD SHARE with creating

3. Given the commands:

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

What does account_123 gain access to?

medium

A. Full access to all objects in sales_db

B. Only metadata about sales_db

C. Usage access to the sales_db database objects shared

D. No access until a role is granted

Solution

1. Step 1: Analyze the GRANT USAGE ON DATABASE to share

   Granting USAGE on a database to a share allows consumers to view database metadata (e.g., SHOW DATABASES, USE DATABASE) but not schemas, tables, or other internal objects.

2. Step 2: Understand the effect of adding accounts

   Adding account_123 to the share provides access limited to the granted privileges: database metadata only, as no schema or table privileges are granted.

3. Final Answer:

   Only metadata about sales_db -> Option B

4. Quick Check:

   GRANT USAGE ON DATABASE = metadata access only [OK]

Hint: GRANT USAGE on DB shares DB metadata only; need schema/table grants for data [OK]

Common Mistakes:

• Assuming full access to all objects in sales_db
• Thinking DB USAGE grants access to internal objects like tables
• Believing roles must be granted separately

4. You run:

CREATE SHARE my_share;
GRANT SELECT ON TABLE sales TO SHARE my_share;

But get an error. What is the likely cause?

medium

A. The table name must be fully qualified with database and schema

B. Shares cannot have privileges granted directly on tables

C. You need to add accounts to the share before granting privileges

D. You must grant privileges on the database, not the table

Solution

1. Step 1: Check the syntax for granting privileges on objects to shares

   Privileges on tables must be granted using fully qualified names: database.schema.table.

2. Step 2: Identify the missing qualification in the command

   The command uses just sales without database and schema, causing an error.

3. Final Answer:

   The table name must be fully qualified with database and schema -> Option A

4. Quick Check:

   Fully qualify table names when granting [OK]

Hint: Always use database.schema.table for grants [OK]

Common Mistakes:

• Granting on database instead of table
• Trying to grant privileges before adding accounts
• Assuming shares can't have table privileges

5. You want to share specific tables from two different databases with multiple accounts. Which approach is best?

hard

A. Create separate shares per database and add accounts to each share accordingly

B. Create one share, grant usage on both databases, and add all tables to it

C. Copy tables into one database, then create a single share

D. Grant privileges directly to accounts without using shares

Solution

1. Step 1: Understand share scope and management

   Shares are scoped to a single database, so sharing tables from different databases requires separate shares.

2. Step 2: Evaluate options for managing multiple accounts and databases

   Creating separate shares per database allows clear control and easier management of access.

3. Step 3: Consider drawbacks of other options

   Copying tables wastes storage; granting privileges directly is less secure and scalable.

4. Final Answer:

   Create separate shares per database and add accounts to each share accordingly -> Option A

5. Quick Check:

   Shares are per database, use multiple shares [OK]

Hint: Use one share per database for multi-db sharing [OK]

Common Mistakes:

• Trying to share multiple databases in one share
• Copying data instead of sharing
• Granting privileges directly to accounts bypassing shares