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