Snowflake Data Sharing Without Copying Data

Snowflake's data sharing capability lets one organisation give another organisation live, read-only access to specific databases, schemas, or tables — without moving, copying, or exporting any data. The recipient queries the data directly inside their own Snowflake account as if the data lived there. The provider's data stays in one place, always current, always controlled by the provider.

This is a fundamental shift from traditional data sharing, which required file exports, FTP transfers, ETL pipelines, and data replication agreements — processes that were slow, expensive, and produced stale copies. Snowflake's sharing is instant, free of data movement, and always reflects the provider's live data.

How Data Sharing Works: The Library Card Analogy

Think of it like a library card system. The library (provider) keeps all its books (data) on its own shelves. It issues a library card (share) to a member (consumer). The member walks into the library and reads any book their card permits — they do not take the book home. The books stay in the library. If the library updates a book, the member reads the updated version on their next visit.

TRADITIONAL DATA SHARING (old way)
=====================================
Provider                              Consumer
--------                              --------
[Database]                            [Their Database]
    |                                       |
    v                                       ^
Extract to CSV ---> FTP transfer ---> Load ETL ---> Stale copy
  (hours)           (minutes)        (hours)        (lags by days)

Problems:
  - Data is stale from the moment it is exported
  - Transfer costs money and time
  - Consumer must manage their own copy
  - Provider loses control once data is transferred

SNOWFLAKE DATA SHARING (new way)
==================================
Provider Account                      Consumer Account
----------------                      ----------------
[Live Database] <-------- No copy -------> [Read Share]
    |                                           |
    v                                           v
Data stays here             Consumer queries run on provider's storage
                            Results computed fresh every time
                            Consumer pays their own warehouse compute
                            Provider's data never leaves their account

Step 1: Provider Creates a Share

The data provider creates a Share object in their Snowflake account and grants access to specific database objects inside it. The Share does not copy data — it creates a set of access permissions that a consumer account can use.

-- As ACCOUNTADMIN in the provider's account:

-- Step 1: Create a share object
CREATE SHARE RETAIL_PARTNER_SHARE
  COMMENT = 'Share aggregated sales data with our retail distribution partner';

-- Step 2: Grant access to the database
GRANT USAGE ON DATABASE RETAIL_DB TO SHARE RETAIL_PARTNER_SHARE;

-- Step 3: Grant access to specific schema
GRANT USAGE ON SCHEMA RETAIL_DB.ANALYTICS TO SHARE RETAIL_PARTNER_SHARE;

-- Step 4: Grant SELECT on specific tables or views
GRANT SELECT ON TABLE RETAIL_DB.ANALYTICS.MONTHLY_SALES
  TO SHARE RETAIL_PARTNER_SHARE;

GRANT SELECT ON TABLE RETAIL_DB.ANALYTICS.PRODUCT_INVENTORY
  TO SHARE RETAIL_PARTNER_SHARE;

-- Step 5: Add the consumer account to the share
ALTER SHARE RETAIL_PARTNER_SHARE
  ADD ACCOUNTS = 'consumer_org.consumer_account_name';
  -- Use the consumer's Snowflake account identifier

-- View current share configuration
SHOW SHARES;
SHOW GRANTS TO SHARE RETAIL_PARTNER_SHARE;

Sharing Views Instead of Raw Tables

Sharing a view is better than sharing a raw table in most cases. A view lets you control exactly which columns and rows the consumer sees, without exposing underlying table structure, sensitive columns, or unfiltered data.

-- Create a view that exposes only safe, aggregated data
CREATE VIEW RETAIL_DB.ANALYTICS.VW_PARTNER_SALES AS
SELECT
    product_category,
    region,
    DATE_TRUNC('WEEK', sale_date)   AS sale_week,
    SUM(revenue)                    AS weekly_revenue,
    COUNT(DISTINCT order_id)        AS order_count
FROM RETAIL_DB.RAW_DATA.SALES_INTERNAL
GROUP BY 1, 2, 3;
-- Consumer sees only weekly summaries by category and region
-- Consumer CANNOT see individual order details, customer names, or prices

-- Share the view (not the raw table)
GRANT SELECT ON VIEW RETAIL_DB.ANALYTICS.VW_PARTNER_SALES
  TO SHARE RETAIL_PARTNER_SHARE;

-- Also share a secure view (hides the view definition from consumer)
CREATE SECURE VIEW RETAIL_DB.ANALYTICS.VW_SECURE_INVENTORY AS
SELECT product_id, product_name, available_qty, last_updated
FROM RETAIL_DB.RAW_DATA.INVENTORY
WHERE available_qty > 0;

GRANT SELECT ON VIEW RETAIL_DB.ANALYTICS.VW_SECURE_INVENTORY
  TO SHARE RETAIL_PARTNER_SHARE;

Secure Views vs Regular Views

REGULAR VIEW                          SECURE VIEW
-----------------                     -----------
Consumer can see the view SQL         Consumer cannot see the view SQL
  (SHOW VIEW reveals the definition)    (definition is hidden)
Snowflake may optimise around the     Snowflake always evaluates the view
  view's WHERE clause for performance   filter before returning data
Use for: performance-critical views   Use for: sharing with external parties
         inside your own account               or hiding business logic

Step 2: Consumer Accesses the Share

The consumer account's ACCOUNTADMIN creates a database from the inbound share. This database acts exactly like a local database inside the consumer's account — they browse it in the Data section, query it in worksheets, and connect BI tools to it. No data is copied.

-- As ACCOUNTADMIN in the consumer's account:

-- Create a local database from the inbound share
CREATE DATABASE SUPPLIER_DATA
  FROM SHARE provider_org.provider_account_name.RETAIL_PARTNER_SHARE;

-- The consumer now sees SUPPLIER_DATA in their account
-- They can query it immediately with their own warehouse

-- Consumer queries the shared data
USE DATABASE SUPPLIER_DATA;
USE SCHEMA ANALYTICS;

SELECT
    product_category,
    sale_week,
    SUM(weekly_revenue)    AS total_revenue,
    SUM(order_count)       AS total_orders
FROM VW_PARTNER_SALES
WHERE sale_week >= DATEADD('month', -3, CURRENT_DATE())
GROUP BY product_category, sale_week
ORDER BY sale_week, total_revenue DESC;
-- This query runs on the CONSUMER's warehouse
-- The PROVIDER's data is read directly from the PROVIDER's storage
-- The CONSUMER pays the compute cost; the PROVIDER pays nothing

Reader Accounts: Sharing with Non-Snowflake Organisations

A consumer must have a Snowflake account to access a shared database. But what if your partner does not use Snowflake? The provider can create a Reader Account — a free, limited Snowflake account managed by the provider — and share data into it. The consumer accesses the Reader Account through a web interface without needing their own Snowflake subscription.

READER ACCOUNT DIAGRAM
========================

PROVIDER ACCOUNT                      READER ACCOUNT
-----------------                     --------------
[Live Database]                        [Share View]
       |                                     |
       |------SHARE---> READER ACCOUNT       |
                        (free, managed       |
                         by provider)        |
                              |              |
                         Consumer logs in    |
                         via web URL         |
                         No Snowflake        |
                         subscription needed |

-- Create a reader account (provider runs this)
CREATE MANAGED ACCOUNT partner_reader_acct
  ADMIN_NAME     = 'reader_admin'
  ADMIN_PASSWORD = 'SecurePass123!'
  TYPE           = READER
  COMMENT        = 'Reader account for logistics partner';

-- Add the reader account to the share
ALTER SHARE RETAIL_PARTNER_SHARE
  ADD ACCOUNTS = partner_reader_acct;

-- Provider creates a warehouse in the reader account for query execution
-- (Provider pays the compute for queries run by the reader account)

Direct Listing vs Private Listing

SHARING METHOD        AUDIENCE               HOW SET UP
--------------        --------               ----------
Direct Share          Specific account IDs   ALTER SHARE ADD ACCOUNTS = '...'
Private Listing       Invited accounts via   Snowflake Marketplace > New Listing
                      Marketplace            > Set visibility to Private
Public Listing        All Snowflake users    Snowflake Marketplace > New Listing
                      globally               > Set visibility to Public
Paid Listing          Paying subscribers     Marketplace listing with pricing
                                             configured through Marketplace

Managing and Monitoring Shares

-- View all outbound shares from your account
SHOW SHARES;

-- View details of a specific share (which objects are in it)
SHOW GRANTS TO SHARE RETAIL_PARTNER_SHARE;

-- View which accounts can access a share
DESC SHARE RETAIL_PARTNER_SHARE;

-- View all inbound shares available to your account
SHOW SHARES LIKE 'inbound';

-- Revoke access from a specific consumer
ALTER SHARE RETAIL_PARTNER_SHARE
  REMOVE ACCOUNTS = 'consumer_org.consumer_account_name';

-- Remove an object from a share
REVOKE SELECT ON TABLE RETAIL_DB.ANALYTICS.MONTHLY_SALES
  FROM SHARE RETAIL_PARTNER_SHARE;

-- Drop an entire share
DROP SHARE RETAIL_PARTNER_SHARE;
-- (Consumer's shared database immediately becomes inaccessible)

-- Monitor query activity on your shared data
SELECT *
FROM SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY
WHERE query_start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
ORDER BY query_start_time DESC;

Data Clean Rooms: Privacy-Preserving Collaboration

A Data Clean Room is an advanced sharing pattern where two organisations analyse overlapping data together without either party seeing the other's raw data. Snowflake implements clean rooms using secure views, row access policies, and joint analysis queries. A common use case is a retailer and an advertiser jointly measuring campaign effectiveness using customer overlap — without either party revealing their raw customer lists to the other.

CLEAN ROOM CONCEPT
===================

RETAILER (Party A)            ADVERTISER (Party B)
------------------            --------------------
[Customer Table]              [Campaign Exposure Table]
  customer_id                   hashed_email
  hashed_email                  campaign_id
  purchase_amount               ad_impression_date

Neither party shares raw tables.

Clean Room:
  Provider creates a secure JOIN view that:
    - Matches hashed emails to find overlap
    - Returns only aggregated results (not individual rows)
    - Hides raw data from both parties

  Both parties query the clean room
  Output: "Campaign X reached 42,000 of your customers. Their post-exposure
           purchase rate was 8.3% vs 5.1% baseline." -- no individual data exposed.

Key Points

  • Snowflake Data Sharing gives consumers live, read-only access to provider data without copying or moving any files
  • The provider creates a Share object, grants database/schema/table access to it, then adds the consumer's account identifier
  • The consumer creates a local database FROM SHARE and queries it using their own warehouse — they pay compute, the provider pays nothing
  • Share secure views instead of raw tables to control which columns and rows consumers see and to hide your view logic
  • Reader Accounts let you share with organisations that do not have Snowflake subscriptions — the provider manages and pays for the reader account
  • Revoking a share is instant — the consumer's shared database becomes immediately inaccessible with no cleanup required
  • Data Clean Rooms enable privacy-preserving joint analysis between two organisations using secure views and aggregated-only outputs
Previous lessons
Back to courses
Next lessons

Leave a Comment

Your email address will not be published. Required fields are marked *