Data Collaboration, Marketplace & Native Apps

How Direct Sharing Works

Snowflake's Secure Data Sharing allows organizations to share live, read-only access to data across Snowflake accounts with zero data copying or movement. The provider's storage is shared directly; consumers use their own virtual warehouses to run queries.

• Shared data is always read-only for consumers
• Provider's storage is the single source of truth — no duplication
• Same-region sharing is free; cross-region requires replication (additional cost)
• Data Providers publish shares; Data Consumers import and mount shares

-- Step 1: Create a share
CREATE SHARE my_share;

-- Step 2: Grant database usage to the share
GRANT USAGE ON DATABASE my_db TO SHARE my_share;
GRANT USAGE ON SCHEMA my_db.public TO SHARE my_share;
GRANT SELECT ON TABLE my_db.public.sales TO SHARE my_share;

-- Step 3: Add consumer account to the share
ALTER SHARE my_share ADD ACCOUNTS = consumer_account;

-- Consumer side: mount the share as a database
CREATE DATABASE shared_db FROM SHARE provider_org.my_share;

What Can Be Added to a Share

Only Secure objects can be added to a share. This protects the implementation logic from being exposed to consumers.

• Secure Views — hides the underlying query logic
• Secure Materialized Views — pre-computed, logic hidden
• Secure UDFs — user-defined functions with hidden definition
• Regular tables and views cannot be added (would expose schema/logic)

Reader Accounts

Non-Snowflake customers can still consume shared data through a Reader Account — a managed Snowflake account created and controlled by the data provider.

• Provider creates the reader account and manages access
• Provider pays for all compute costs in the reader account
• Reader accounts cannot share data with other accounts
• Use case: sharing data with customers or partners who do not have Snowflake

Marketplace Overview

The Snowflake Marketplace is a public catalog for discovering and accessing third-party data products with no ETL, no data movement, and instant access.

• Public Listings: anyone can discover; may require request approval before access is granted
• Private Listings: shared with specific named accounts only; not publicly discoverable
• Personalized Listings: provider sends a customized data slice tailored to a specific consumer

Use cases include financial data feeds, weather data, demographic reference data, location intelligence, and compliance datasets.

Data Exchange vs Marketplace

A Data Exchange is an organization's private, invitation-only version of the Marketplace. Members must be explicitly invited — it is not publicly discoverable.

• Create a Data Exchange for internal org use or vetted external partners
• Exchange admin manages providers and consumers
• Primary use case: enterprise data mesh — business units sharing curated data assets across the organization
• Key distinction from Marketplace: Data Exchange = private; Marketplace = public

Privacy-Preserving Collaboration

Data Clean Rooms enable two organizations to analyze overlapping datasets (e.g., shared customer lists) without either party seeing the other's raw data.

• Analysis results are shared; raw data is never exposed
• Built on: Secure Functions + Row Access Policies + Secure Views
• Consumers only see aggregate or joined results — not individual records
• Powered by the Snowflake Native App Framework

Use cases: advertiser + publisher audience overlap analysis, healthcare research collaboration, financial fraud detection across institutions.

Apps That Come to the Data

The Snowflake Native App Framework allows providers to build, publish, and distribute applications that install and run directly inside the consumer's Snowflake account.

• Consumer installs the app; app logic runs in the consumer's account
• Data never leaves the consumer's account — the app comes to the data
• Providers package SQL, Python, and JavaScript logic as a Native App
• Published via Marketplace or Private Listings
• Powers Data Clean Room functionality

Use cases: analytics tools, data enrichment services, operational applications, compliance tools.

Replication for Cross-Region Sharing

For zero-copy sharing to work, the consumer must be in the same region as the provider. For cross-region access, data must be replicated first.

• Database Replication: replicate a database to a different region/cloud account
• Account Replication: replicate account-level objects (users, roles, warehouses, resource monitors)
• Failover/Failback: designate primary and secondary databases for disaster recovery

-- Enable cross-region replication for a database
ALTER DATABASE my_db ENABLE REPLICATION TO ACCOUNTS
  aws.us-east-1.consumer_account;

-- On the consumer side, create a secondary database
CREATE DATABASE my_db_replica AS REPLICA OF
  aws.us-west-2.provider_account.my_db;