Snowflake Marketplace and Data Exchange: Commercial Data Sharing at Scale

Snowflake Secure Data Sharing is one of the most strategically important features in the modern data stack. The ability to share live data across Snowflake accounts — without copying data, without building ETL pipelines, without managing APIs or file transfers — changes what is architecturally possible for organisations that need to exchange data with partners, customers, or subsidiaries.

This guide covers how Snowflake data sharing works technically, when to use it versus alternatives, governance considerations, and the operational patterns that distinguish well-implemented sharing from a governance disaster.

How Snowflake Data Sharing Works

Traditional data sharing requires copying data: extract it from the source system, transform it, load it into a destination the recipient can access. This creates multiple problems: the copy is stale the moment it is created, you have no control over what the recipient does with it, and you have to maintain the extract and load process indefinitely.

Snowflake data sharing is fundamentally different. **A data share in Snowflake is a named database object that grants read access to specific database objects (tables, views, secure views) in one Snowflake account to another Snowflake account.** The recipient does not get a copy of the data. They query the provider's data directly, with Snowflake handling the access control and billing separation transparently.

From the recipient's perspective, the shared database appears in their account like any other read-only database. They can query it, join it to their own tables, build views against it, use it in their BI tools. But they cannot modify it, extract a copy without significant effort, or see data the provider has not explicitly shared.

From the provider's perspective, the shared data is always current — recipients always see live data. Access can be revoked instantly. The provider's own compute costs are not affected by recipient queries (recipients pay for the compute they use to query shared data).

Core Concepts

**Data Provider**: the Snowflake account that owns the data and creates the share.

**Data Consumer**: the Snowflake account that receives access through the share. Can be any Snowflake account on any cloud or region, subject to cross-region replication considerations.

**Share Object**: the named object in the provider account that defines what is being shared. A share can contain: tables, external tables, views, secure views, and secure materialized views. Dynamic tables are also shareable in current Snowflake versions.

**Secure Views**: when sharing views, Snowflake requires that they be defined as SECURE views. A secure view hides its definition from the recipient — they can query it but cannot see the underlying SQL. This is critical for sharing derived data without exposing proprietary calculation logic or sensitive source columns.

**Database Roles**: a newer mechanism (alongside the older share-based model) that allows sharing subsets of a database using role-based access control patterns. Database roles provide more granular control than raw shares.

Creating a Data Share

The provider workflow:

CREATE SHARE partner_share;

GRANT USAGE ON DATABASE analytics TO SHARE partner_share;

GRANT USAGE ON SCHEMA analytics.public TO SHARE partner_share;

GRANT SELECT ON TABLE analytics.public.daily_sales_summary TO SHARE partner_share;

GRANT SELECT ON SECURE VIEW analytics.public.customer_metrics_v TO SHARE partner_share;

ALTER SHARE partner_share ADD ACCOUNTS = partner_account_identifier;

The consumer workflow — once added to the share, the recipient creates a database from the share:

CREATE DATABASE partner_data FROM SHARE provider_account.partner_share;

SELECT * FROM partner_data.public.daily_sales_summary;

That is the complete workflow. No credentials to manage. No ETL. No lag. The recipient is querying live data.

The Snowflake Marketplace

The Snowflake Marketplace extends data sharing to public distribution. Providers can list their data products on the Marketplace — either free or commercially priced — and any Snowflake customer can discover, request, and consume them without any direct relationship with the provider.

Common Marketplace use cases:

- **Third-party data enrichment**: weather data, demographic data, financial market data, geolocation data

- **Industry benchmarks**: aggregated industry metrics that companies contribute to and receive in return

- **Reference data**: postal codes, currency exchange rates, product classification taxonomies

- **Data products as revenue**: organisations that have built valuable datasets can distribute them commercially

From an architecture standpoint, Marketplace data is treated identically to directly shared data — it appears as a read-only database in your account that you can join to your own tables. This is architecturally cleaner than API integrations or file-based data purchases: the data lives in Snowflake, the joins are native, and you do not need to build an ingestion pipeline.

Cross-Region and Cross-Cloud Sharing

By default, a share only works between accounts in the same cloud region (same cloud provider, same region). For cross-region or cross-cloud sharing, you need **replication**.

Snowflake's database replication feature creates a replica of the database in a target region/cloud, which is then shared from the replica. Replication has a lag (typically minutes) and a cost (replication compute and storage). But for truly global data exchange — provider on AWS us-east-1, consumer on Azure West Europe — it is the only mechanism.

For real-time requirements where replication lag is unacceptable, design the architecture around same-region sharing, which is zero-lag.

Governance Considerations

Data sharing dramatically lowers the friction of sharing data. This is a feature, but it creates governance risk if not managed carefully.

**What are you sharing?** Every share should have a documented inventory: which tables or views, what data they contain, any PII or sensitive fields, the classification level. Before creating a share, the data governance team should approve the objects being shared.

**With whom?** Shares to named accounts are relatively controlled. Marketplace listings are accessible to any Snowflake customer who requests them — either automatically or after manual approval. Marketplace distribution decisions should involve legal and compliance review.

**Row-level and column-level security.** Snowflake supports row access policies and column masking policies that apply to queries from consumers. A consumer querying a shared table with a row access policy applied will only see rows the policy permits — even though they are reading the provider's data directly. This allows sharing a single table with multiple consumers with different data visibility, without creating multiple views.

**Auditing.** Query history for consumer queries against shared data appears in the consumer account's query history, not the provider's. If you need to audit what consumers are doing with shared data, you need consumers to enable and share that query history — or use Snowflake's account usage views, which log share access events.

**Data use agreements.** Technical access control does not substitute for contractual data use agreements. Sharing data with a partner via Snowflake does not prevent them from querying, aggregating, and exporting derived insights. Ensure your data sharing relationships have appropriate legal agreements governing data use.

Secure Views for Safe Sharing

When sharing derived metrics rather than raw tables, secure views are the right pattern. A secure view allows you to:

- **Exclude sensitive columns**: the consumer sees the view result, not the underlying table with its PII columns

- **Apply business logic**: share a pre-aggregated daily summary instead of transaction-level detail

- **Hide proprietary calculations**: the view definition is invisible to the consumer

- **Implement row-level filtering**: filter to the consumer's own data in a multi-tenant shared view

CREATE SECURE VIEW analytics.public.partner_orders_v AS

SELECT order_date, product_sku, quantity, revenue

FROM analytics.raw.orders

WHERE partner_id = CURRENT_ACCOUNT()

AND order_date >= DATEADD('day', -90, CURRENT_DATE);

CURRENT_ACCOUNT() resolves to the consumer's account identifier at query time, allowing a single secure view to return filtered results to each consumer automatically.

Use Cases

**Partner data exchange**: share operational metrics, sales data, or inventory levels with distribution partners, suppliers, or resellers — without file transfers or API integrations. Each partner sees their own data, with the filtering logic in the secure view.

**Customer-facing analytics**: provide customers with a Snowflake share containing their own usage data, billing summaries, or performance metrics. More powerful than a dashboard — customers can query their data in their own BI tools.

**Subsidiary and inter-department sharing**: large enterprises with multiple Snowflake accounts (separate accounts per business unit, per region, or per environment) can share data between accounts without replication infrastructure. The finance account shares budget data with the analytics account; the data platform team shares curated datasets with business unit teams.

**Data monetisation**: if your organisation has collected data that has value to others in your industry, the Snowflake Marketplace provides a distribution channel with built-in billing, access control, and consumer management.

**Replacing file-based data exchange**: anywhere you currently exchange data via SFTP, S3 bucket access, or API, Snowflake data sharing is a simpler, more governed, always-current alternative — if both parties use Snowflake.

Performance Considerations

Consumer queries against shared data run on the consumer's compute (their virtual warehouses). The provider's compute is not affected by consumer queries. This is architecturally important: you can share a high-traffic dataset with many consumers without any performance impact on your own workloads.

However, shared tables are read from the provider's storage, subject to the same physical layout optimisations that apply to any Snowflake table. Applying appropriate **clustering keys** to frequently queried columns on the provider side will improve consumer query performance exactly as it improves provider query performance.

Shared objects respect Snowflake's standard query optimisation — result caching, micro-partition pruning, column pruning. A well-structured shared table will perform as well for consumers as it does for the provider.

For our guide on Snowflake cost management and performance optimisation more broadly, see snowflake cost management. For data architecture questions involving Snowflake, our data architecture consulting team is available — contact us to discuss your requirements.

A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.