Data Sharing: Secure Sharing, Marketplace & Direct Shares

Architecture Diagram 1: Data Sharing Architecture

Architecture Diagram 2: Data Marketplace Architecture

Architecture Diagram 3: Data Exchange Architecture

Architecture Diagram 4: Data Sharing Security Model

Detailed Explanation

What is Secure Data Sharing?

Real-time data sharing between Snowflake accounts without data movement or copying. Consumers access the same micro-partitions as providers via metadata pointers.

How Sharing Works

• Leverages micro-partition architecture — no data duplication
• Zero latency — updates available instantly
• Shared data is read-only by design
• Consumers can create local copies via CLONE or INSERT...SELECT

Data Marketplace

• Curated ecosystem for publishing and discovering data products
• Listing types: Free, Paid (Consumption), Paid (Subscription)
• Marketplace data appears as local tables in consumer accounts
• Queries execute in provider's warehouse

Data Exchange

• Controlled multi-party sharing environments
• Types: Private (invite-only), Secure (verified), Public (marketplace)
• Administrator manages enrollment, policies, and monitoring
• Useful for industry consortia and partner ecosystems

Billing and Usage Tracking

• SHARING_HISTORY view tracks consumer access patterns
• No storage duplication — consumer reads provider's data in-place

Key Takeaway: Data sharing is ideal for data products monetization, supply chain partners, and multi-tenant analytics. Use Secure Views to prevent metadata leakage.

Key Concepts Table

Code Examples

Direct Share: Provider Side

-- Example 1: Create a share
-- A share is a named object that contains pointers to database objects
-- The share itself does not store data; it references objects in the provider database
CREATE SHARE analytics_share
    COMMENT = 'Share for analytics data';

-- Example 2: Add objects to share
-- GRANT USAGE is required on DATABASE and SCHEMA before sharing tables/views
-- GRANT SELECT shares the actual table data with consumers
GRANT USAGE ON DATABASE analytics_prod TO SHARE analytics_share;
GRANT USAGE ON SCHEMA analytics_prod.shared_data TO SHARE analytics_share;
GRANT SELECT ON TABLE analytics_prod.shared_data.sales_data TO SHARE analytics_share;
GRANT SELECT ON TABLE analytics_prod.shared_data.customer_dim TO SHARE analytics_share;
-- You can also share views (useful for pre-aggregated or secured data)
GRANT SELECT ON VIEW analytics_prod.shared_data.sales_summary TO SHARE analytics_share;

-- Example 3: Add consumer accounts to share
-- Multiple accounts can be added in a single statement
-- Use ACCOUNT Locator or Organization Name + Account Name
ALTER SHARE analytics_share ADD ACCOUNTS = consumer_account_1, consumer_account_2;

-- Example 4: Remove a consumer from a share
ALTER SHARE analytics_share REMOVE ACCOUNTS = consumer_account_2;

-- Example 5: Modify share properties
ALTER SHARE analytics_share SET COMMENT = 'Updated share for Q4 analytics';

-- Example 6: View share details
DESC SHARE analytics_share;
SHOW SHARES LIKE 'analytics_%';

Direct Share: Consumer Side

-- Example 7: Consumer creates database from share
-- The database name can differ from the share name
-- Consumer can only create ONE database per share
CREATE DATABASE analytics_share_db
    FROM SHARE provider_account.analytics_share;

-- Example 8: Query shared data
-- Shared data is read-only; no INSERT/UPDATE/DELETE allowed
-- Consumer can JOIN shared tables with local tables
SELECT 
    s.product,
    s.region,
    SUM(s.amount) as total_sales,
    c.customer_segment
FROM analytics_share_db.shared_data.sales_data s
JOIN analytics_share_db.shared_data.customer_dim c
ON s.customer_id = c.customer_id
GROUP BY 1, 2, 4;

-- Example 9: Create view on shared data (local enrichment)
-- Consumer can create views that combine shared and local data
CREATE VIEW local_analytics AS
SELECT 
    s.*,
    l.local_enrichment_column
FROM analytics_share_db.shared_data.sales_data s
LEFT JOIN local_enrichment_table l
ON s.id = l.id;

-- Example 10: Create a clone of shared data for modification
-- Consumer can clone shared tables if they need to modify data
CREATE TABLE sales_clone CLONE analytics_share_db.shared_data.sales_data;
-- Now consumer can modify sales_clone independently
UPDATE sales_clone SET amount = amount * 1.1 WHERE region = 'US';

Monitoring and Governance

-- Example 11: Monitor sharing usage (Provider perspective)
-- SHARING_HISTORY shows which consumers are querying shared data
SELECT 
    share_name,
    consumer_account,
    consumer_region,
    queries_executed,
    bytes_scanned,
    last_query_time
FROM TABLE(INFORMATION_SCHEMA.SHARING_HISTORY(
    SHARE_NAME => 'analytics_share',
    START_TIME => DATEADD(day, -30, CURRENT_TIMESTAMP())
))
ORDER BY last_query_time DESC;

-- Example 12: List all shares in your account
SHOW SHARES LIKE 'analytics_%';

-- List shares from specific provider
SHOW SHARES IN ACCOUNT provider_account;

-- Get detailed share information
DESC SHARE analytics_share;

-- Example 13: Monitor shared database usage
SELECT 
    share_name,
    consumer_account,
    database_name,
    schema_name,
    table_name,
    bytes_scanned,
    queries_executed
FROM TABLE(INFORMATION_SCHEMA.SHARING_HISTORY(
    START_TIME => DATEADD(day, -7, CURRENT_TIMESTAMP())
))
ORDER BY bytes_scanned DESC;

Data Marketplace

-- Example 14: Create a Marketplace listing
-- Providers publish data products for consumer discovery
CREATE LISTING weather_data_listing
    TITLE = 'Global Weather Forecasts'
    DESCRIPTION = 'Daily weather forecasts with 5-year history'
    COMMENT = 'Weather data for analytics'
    PROTOCOL = SNOWFLAKE          -- Protocol for data delivery
    IMPORT = TRUE                 -- Consumer can import data locally
    QUERY_ANYWARE = TRUE          -- Consumer can query without importing
    TERMS = 'Free for non-commercial use'
    CATEGORY = 'Weather'
    PROVIDER_NAMESPACE = 'my_org';

-- Example 15: Browse available Marketplace listings
-- Consumers search and discover data products
SHOW LISTINGS LIKE '%weather%';

-- Get listing details
DESC LISTING weather_data_listing;

-- Example 16: Get data from Marketplace
-- Consumer accepts terms and creates local database from listing
CREATE DATABASE weather_data
    FROM LISTING weather_data_listing;

-- Query imported Marketplace data
SELECT * FROM weather_data.forecasts 
WHERE city = 'New York' 
AND forecast_date = CURRENT_DATE();

Data Exchange

-- Example 17: Create a private Data Exchange
-- Data Exchange enables controlled multi-party sharing
CREATE DATA EXCHANGE partner_exchange
    TYPE = PRIVATE                   -- PRIVATE, SECURE, or PUBLIC
    COMMENT = 'Private exchange for partner data collaboration';

-- Example 18: Add participants to exchange
-- PROVIDER participants share data; CONSUMER participants access it
ALTER DATA EXCHANGE partner_exchange ADD PARTICIPANT 
    PARTICIPANT_TYPE = PROVIDER
    ACCOUNT_NAME = partner_financial_account;

ALTER DATA EXCHANGE partner_exchange ADD PARTICIPANT 
    PARTICIPANT_TYPE = CONSUMER
    ACCOUNT_NAME = customer_bank_account;

-- Example 19: List exchange participants
SHOW DATA EXCHANGES LIKE 'partner_%';

-- Example 20: Provider publishes to exchange
-- After adding to exchange, provider creates a listing within the exchange
CREATE LISTING financial_data_listing
    TITLE = 'Real-time Market Data'
    DATA_EXCHANGE = partner_exchange
    PROTOCOL = SNOWFLAKE
    QUERY_ANYWARE = TRUE;

-- Example 21: Consumer accesses exchange listing
CREATE DATABASE market_data
    FROM LISTING financial_data_listing;

-- Example 22: Monitor exchange usage
SELECT 
    listing_name,
    consumer_account,
    queries_executed,
    bytes_scanned,
    last_access_time
FROM TABLE(INFORMATION_SCHEMA.SHARING_HISTORY(
    START_TIME => DATEADD(day, -30, CURRENT_TIMESTAMP())
))
WHERE share_name LIKE '%exchange%'
ORDER BY bytes_scanned DESC;

-- Example 23: Revoke share access
-- Provider can remove consumer access at any time
ALTER SHARE analytics_share REMOVE ACCOUNTS = old_consumer_account;

-- Example 24: Drop share (must remove all consumers and objects first)
-- Unshare all objects
REVOKE SELECT ON TABLE analytics_prod.shared_data.sales_data FROM SHARE analytics_share;
REVOKE USAGE ON SCHEMA analytics_prod.shared_data FROM SHARE analytics_share;
REVOKE USAGE ON DATABASE analytics_prod FROM SHARE analytics_share;
-- Remove all consumers
ALTER SHARE analytics_share REMOVE ACCOUNTS = consumer_account_1;
-- Drop the share
DROP SHARE analytics_share;

Performance Metrics

Best Practices

1. Document data schemas: Provide comprehensive documentation for shared data including schemas, data types, update frequencies, and quality metrics.

2. Monitor usage patterns: Track which consumers are accessing your data, query volumes, and resource consumption to optimize data products.

3. Implement data quality checks: Validate shared data regularly and communicate quality issues proactively to consumers.

4. Set appropriate pricing: Consider the value of your data, update frequency, and consumer usage patterns when setting pricing.

5. Use appropriate listing types: Choose free listings for discovery, consumption-based for variable workloads, and subscriptions for predictable workloads.

6. Monitor query performance: Ensure shared data queries execute efficiently. Consider clustering and optimization for frequently accessed data.

7. Implement access controls: Use Snowflake's sharing features to control who can access your data and under what conditions.

8. Plan for scale: Design shared data structures to handle growth in data volume and consumer demand.

9. Communicate updates: Notify consumers of data updates, schema changes, or service interruptions.

10. Review sharing agreements: Regularly review sharing terms, pricing, and usage to ensure they remain appropriate for all parties.

Additional Theory: Data Sharing Security Model

Snowflake's data sharing security is built on three pillars:

1. Zero-copy architecture: Data never leaves the provider's cloud storage. Consumers receive a metadata pointer that grants read access to the same micro-partitions the provider owns. This eliminates data duplication and ensures a single source of truth.

2. Role-based access control: Providers control sharing through GRANT statements on specific objects. Consumers cannot modify, re-share, or grant privileges on shared data. This ensures data integrity and prevents unauthorized distribution.

3. Cross-cloud federation: Snowflake's architecture enables sharing across AWS, Azure, and GCP without data movement. The cloud services layer handles authentication and query routing, while data remains in the provider's cloud storage.

Compliance considerations:

• Shared data is subject to the provider's data residency policies
• Consumers inherit provider's data classification labels
• Audit trails track all access to shared objects via ACCESS_HISTORY

Additional Theory: Marketplace Pricing Models

See Also

• 05-Access-Control-RBAC - Role-based access control for shares
• 09-Streams-Tasks - Automating data sharing pipelines
• 16-Dynamic-Data-Masking - Masking shared data for consumers
• PySpark Iceberg - Iceberg data sharing patterns
• Delta Lake on Databricks - Delta Lake sharing model
• Data Warehouse Concepts - Data warehouse design principles