5.3 Snowflake Marketplace, Data Exchange & Clean Rooms

5.3 Snowflake Marketplace, Data Exchange & Clean Rooms

As enterprise collaboration models evolve beyond point-to-point direct sharing, architectures require broader discovery mechanisms, commercial monetization capabilities, and privacy-preserving multi-party computing. Snowflake provides three advanced collaboration tiers:

1. Snowflake Marketplace: A public or private commercial marketplace connecting thousands of data providers and consumers across global cloud regions.
2. Snowflake Data Exchange: A private, branded collaboration portal with centralized governance, designed for corporate ecosystems, partner consortia, and enterprise subsidiaries.
3. Snowflake Data Clean Rooms (DCR): A privacy-enhancing computation framework that allows multiple parties to join and analyze sensitive datasets without exposing underlying raw records or Personally Identifiable Information (PII).

Collaboration Solutions Comparison Matrix

Snowflake Marketplace: Architecture, Monetization & Auto-Fulfillment

The Snowflake Marketplace allows organizations to discover, evaluate, and access third-party data products, Snowflake Native Apps, and AI models directly within their Snowflake accounts without building ETL pipelines.

Listing Types: Public vs. Private

1. Public Listings:
   • Discoverable by any Snowflake customer worldwide.
   • Published in the public Marketplace catalog after passing Snowflake's automated security review and manual curation.
   • Can be offered as Free (instant mount) or Personalized (requires consumer request and provider approval).
2. Private Listings:
   • Hidden from the public Marketplace directory.
   • Targeted specifically to designated consumer accounts via organization account identifiers.
   • Used for bespoke enterprise agreements, customized schemas, negotiated pricing, and proprietary partner data feeds.

Commercial Monetization Models

Providers can monetize data products and Native Apps directly on the Marketplace using two primary billing models:

• Paid listings with Snowflake billing: Providers define pricing plans (for example usage-based or subscription pricing), Snowflake bills the consumer through its Snowflake invoice, and disbursements to providers are reported in views such as MARKETPLACE_DISBURSEMENT_REPORT. Paid listings delivered to other regions must use auto-fulfillment.
• External / Custom Contract Billing: The consumer and provider negotiate commercial terms off-platform (custom master service agreements). Once executed, the provider grants access to a private or personalized listing.

Cross-Cloud Auto-Fulfillment (CRITICAL ARCHITECTURAL COMPONENT)

In global enterprises, data providers on one cloud and region (e.g., AWS us-east-1) face consumers deployed across diverse platforms (e.g., Azure westeurope and GCP us-central1). Standard direct sharing cannot cross these boundaries.

Cross-Cloud Auto-Fulfillment solves this by automating cross-cloud and cross-region replication:

┌────────────────────────────────────────────────────────────────────────┐
│                     DATA PROVIDER (Primary Account)                    │
│                         AWS us-east-1 (N. Virginia)                    │
│                                                                        │
│   ┌─────────────────────┐               ┌──────────────────────────┐   │
│   │   Primary Database  │──────────────►│   Marketplace Listing    │   │
│   │  (Source Analytics) │               │ (Auto-Fulfillment Active)│   │
│   └──────────┬──────────┘               └─────────────┬────────────┘   │
└──────────────┼────────────────────────────────────────┼────────────────┘
               │ Serverless Cross-Cloud Replication     │ Replicates Listing
               ▼                                        ▼ Metadata
┌────────────────────────────────────────────────────────────────────────┐
│              SECURE SHARE AREA (Managed by Snowflake)                  │
│                         Azure West Europe (Netherlands)                │
│                                                                        │
│   ┌─────────────────────┐               ┌──────────────────────────┐   │
│   │ Replicated Data     │──────────────►│ Local Listing Share      │   │
│   │ Database (Read-Only)│               │ (Mounted by Consumers)   │   │
│   └─────────────────────┘               └─────────────┬────────────┘   │
└───────────────────────────────────────────────────────┼────────────────┘
                                                        │ Local Query
                                                        ▼ (No Egress)
┌────────────────────────────────────────────────────────────────────────┐
│                      CONSUMER ACCOUNT (Local Region)                   │
│                         Azure West Europe (Netherlands)                │
└────────────────────────────────────────────────────────────────────────┘

1. Managed delivery: With auto-fulfillment enabled, Snowflake provisions and manages a secure share area (SSA) in each remote region and fulfills the listing's data product (a share or an application package) there. Private listings are fulfilled after the specified consumers get the listing; public listings after a consumer in that region gets it.
2. Refresh options: Providers choose an interval-based refresh (from one minute to eight days), a schedule-based refresh, or trigger a refresh on demand with SYSTEM$TRIGGER_LISTING_REFRESH after upstream ETL finishes.
3. Billing Responsibility: The provider pays auto-fulfillment costs (replication compute, data transfer, and storage in remote regions); consumers pay for the warehouses they use to query the data.

Snowflake Data Exchange: Private Collaborative Ecosystems

While the Snowflake Marketplace is a global public catalog, a Snowflake Data Exchange is a private, secure, and branded data marketplace created specifically for an enterprise's trusted business ecosystem.

Architectural Use Cases

• Multi-Subsidiary Enterprise Data Mesh: A global conglomerate with forty operating companies across banking, insurance, and retail uses a Data Exchange to discover and consume standardized enterprise data assets without building point-to-point shares.
• Supply Chain & Franchise Networks: A major automobile manufacturer coordinates with 500 tier-one parts suppliers and 2,000 independent dealerships, sharing component telemetry, inventory projections, and warranty claims.
• Healthcare & Clinical Consortia: Research hospitals and pharmaceutical companies share patient cohort benchmarks under strict compliance terms.

The Data Exchange Governance Model

The Data Exchange introduces a specialized administrative hierarchy:

A Data Exchange is not enabled by default; an organization requests a new Data Exchange from Snowflake Support, and administration happens mainly in Snowsight:

1. Data Exchange Admin: The Snowflake account that hosts the exchange. A user with ACCOUNTADMIN in that account adds or removes members and designates each member as a provider, consumer, or both; these administrative privileges can be delegated to other roles.
2. Providers: Members that create listings, choose free or personalized access, publish them, and can grant access to consumers in other regions.
3. Consumers: Members that browse the exchange, switch between it and the Snowflake Marketplace, and get data instantly or by request.
4. Governance: The admin manages membership and access, audits usage, and applies security controls to shared data.

Architect Tip: For sharing inside one organization, Snowflake also offers organizational listings (the internal marketplace), which avoid setting up a separate exchange.

Snowflake Data Clean Rooms (DCR): Privacy-Preserving Architecture

Modern data collaboration frequently encounters scenarios where two or more parties want to collaborate, but neither party can expose raw records or Personally Identifiable Information (PII) to the other. Examples include:

• An e-commerce retailer and an online streaming platform matching audiences to measure advertising conversion lift.
• Two financial institutions joining fraud detection signals without sharing client account numbers.
• A hospital system and a biotech researcher comparing patient genetic markers with treatment outcomes.

A Snowflake Data Clean Room is Snowflake's managed collaboration framework that lets multiple parties analyze each other's data without either party seeing the other's raw records.

How Snowflake Data Clean Rooms Are Organized

• A collaboration is defined by a YAML specification that names collaborators and their roles.
• Roles: the owner creates the collaboration and decides who participates; data providers contribute data offerings (tables or views with column and policy rules); analysis runners execute permitted templates.
• Templates are JinjaSQL queries the collaborators approve; runners can only fill in allowed parameters. Code specs add approved Python logic.
• Collaborations are managed in Snowsight or through the Collaboration API. Data providers must use Enterprise Edition; clean rooms are not available on trial accounts, and Cross-Cloud Auto-Fulfillment lets collaborators in other regions participate.

The privacy techniques below are the building blocks these templates and policies rely on:

┌────────────────────────────────────────────────────────────────────────┐
│                     PARTY A: RETAILER ACCOUNT                          │
│  Raw Table: Customers (Hashed Email, Zip Code, Purchase Total)         │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │ Protected via Clean Room
                                    │ Secure UDFs & Match Keys
                                    ▼
┌────────────────────────────────────────────────────────────────────────┐
│                    DATA CLEAN ROOM GOVERNANCE LAYER                    │
│                                                                        │
│   1. Cryptographic Match Join:                                         │
│      ON sha256(A.email) = sha256(B.email)                              │
│                                                                        │
│   2. Pre-Approved Parameterized Query Templates:                       │
│      (Arbitrary ad-hoc SQL queries are strictly blocked)                │
│                                                                        │
│   3. Differential Privacy & Noise Addition:                            │
│      Aggregate Output: Count = True Count + Laplace_Noise              │
│                                                                        │
│   4. Minimum Aggregation Thresholds:                                   │
│      HAVING count(distinct user_id) >= 100                             │
│      (Eliminates small-cohort re-identification attacks)               │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │ Only Aggregated, Privacy-Compliant
                                    │ Metrics Released
                                    ▼
┌────────────────────────────────────────────────────────────────────────┐
│                     PARTY B: MEDIA PUBLISHER ACCOUNT                   │
│  Receives Final Insight: "Overlap Cohort: 14,250 users | Lift: +14.2%" │
│  (ZERO raw rows, ZERO plain emails, ZERO individual transaction data)  │
└────────────────────────────────────────────────────────────────────────┘

The Six Security Primitives of a Data Clean Room

To pass the SnowPro Advanced: Architect exam, you must master the technical primitives that make a Data Clean Room mathematically secure:

1. Zero Raw Data Movement

Neither party exports or transfers raw data files. Both parties store their data inside their own respective Snowflake accounts. The clean room connects datasets via Secure Shares and Secure Views.

2. Cryptographic Match Keys (One-Way Hashing)

Direct identifiers (email addresses, phone numbers, government IDs) are never compared in plaintext. Both parties preprocess sensitive columns using standardized one-way cryptographic hashing (such as salted SHA256) or privacy-preserving identity resolution tokens (e.g., Unified ID 2.0):

-- Standardizing match key before clean room ingestion
SELECT 
    SHA2(LOWER(TRIM(email_address)), 256) AS hashed_join_key,
    zip_code,
    purchase_amount
FROM internal_sales;

3. Pre-Approved Query Templates (Strict Ad-Hoc Blocking)

In a Data Clean Room, users cannot execute arbitrary ad-hoc SQL. If an analyst were permitted to run SELECT * FROM partner_data or craft complex nested subqueries, they could reverse-engineer individual identities. Instead, analytics run through pre-approved templates (JinjaSQL in Snowflake Data Clean Rooms). Collaborators review and approve the template definitions beforehand. Analysts can only pass approved parameters (such as campaign date ranges or target demographic categories).

4. Minimum Aggregation Thresholds (Cohort Floors)

A common inference attack involves querying overlapping cohorts with narrow filters until a cohort is reduced to a single individual (e.g., "Female, age 47, ZIP 94102, diagnosed with Condition X"). Clean rooms mitigate this by enforcing a Minimum Threshold Constraint in all query templates:

-- Clean room query template enforces non-negotiable aggregate floor
SELECT 
    p.campaign_name,
    COUNT(DISTINCT r.hashed_join_key) AS matched_consumers,
    SUM(r.purchase_amount) AS total_attributed_revenue
FROM media_impressions p
JOIN retailer_sales r
  ON p.hashed_join_key = r.hashed_join_key
WHERE p.campaign_id = :campaign_id
HAVING COUNT(DISTINCT r.hashed_join_key) >= 100; -- Fails if cohort < 100

If the matching population contains fewer than the threshold (e.g., 100 distinct individuals), the query returns zero rows or aborts with an error, preventing single-individual identification.

5. Differential Privacy & Noise Addition

Even with cohort floors, an attacker can compare two aggregate queries (one containing 101 people and another containing 100 people) to deduce the exact values of the single differing individual (a differencing attack). Snowflake supports differential privacy (an Enterprise Edition privacy-policy capability that clean rooms can use). Calibrated noise is added to aggregate results so that the presence or absence of any single individual cannot be reliably inferred, at the cost of some accuracy.

6. Strict Projection Constraints

Raw join keys, quasi-identifiers (such as birthdate combined with 5-digit ZIP code), and unaggregated transaction records can never appear in the SELECT, GROUP BY, or ORDER BY clauses of a clean room output.