Data Sharing: Listings & Marketplace Deep Dive

In the modern data ecosystem, sharing data across teams, partners, and customers is a critical capability. Traditional methods—exporting CSV files, setting up FTP transfers, or building complex ETL pipelines—are slow, error-prone, and create data silos. Snowflake revolutionizes this with its native data sharing, listings, and Marketplace, enabling instant, secure, and governed data collaboration without moving or copying data.

Snowflake data sharing allows you to share live, queryable data from one Snowflake account to another. The shared data remains in the provider's account, so consumers always see the latest version. There's no data duplication, no storage costs for the consumer, and no complex infrastructure. Listings extend this concept by packaging shared data into discoverable products on the Snowflake Marketplace. Providers can publish listings—either publicly to all Snowflake users or privately to specific accounts—and consumers can access them with a few clicks.

This tutorial will guide you through the entire lifecycle: setting up data sharing, creating listings, managing access, and best practices for production. You'll learn how to share data securely using secure views and row-level security, how to monetize your data assets, and how to troubleshoot common issues. By the end, you'll be able to build a data sharing strategy that scales with your organization.

Understanding Snowflake Data Sharing Concepts

Snowflake data sharing is built on a provider-consumer model. The provider creates a share, adds objects (databases, schemas, tables, views, secure views, or secure materialized views), and grants access to one or more consumer accounts. Consumers see the shared data as a read-only database in their own account, with no storage costs. The data is always live—any changes made by the provider are immediately visible to consumers.

When you share a view, the consumer can query it like any other view. However, if you share a table directly, the consumer sees all rows. Secure views are preferred for production because they allow you to apply filters (e.g., only show rows where region = 'US') without exposing the underlying data.

-- Provider account: Create a share and add objects
CREATE SHARE my_share;

-- Grant usage on the database and schema
GRANT USAGE ON DATABASE sales_db TO SHARE my_share;
GRANT USAGE ON SCHEMA sales_db.public TO SHARE my_share;

-- Add a secure view to the share
GRANT SELECT ON VIEW sales_db.public.secure_sales_summary TO SHARE my_share;

-- Grant access to a consumer account
ALTER SHARE my_share SET ACCOUNTS = 'CONSUMER_ACCOUNT_LOCATOR';

Setting Up a Consumer Account and Querying Shared Data

Once the provider grants access to a consumer account, the consumer can import the share into their account. This creates a read-only database that references the provider's data. The consumer does not store any data; every query runs on the provider's side.

Steps for the consumer: 1. The provider must know the consumer's account locator (found in the consumer's Snowflake URL or via SELECT CURRENT_ACCOUNT()). 2. The provider runs ALTER SHARE share_name SET ACCOUNTS = consumer_account_locator;. 3. The consumer runs CREATE DATABASE shared_db FROM SHARE provider_account_locator.share_name;. 4. The consumer can now query the shared database like any other database.

Note: The consumer cannot modify the shared data. They can create views, materialized views, or tables on top of the shared data (by copying data into their own tables), but the original shared data remains read-only.

If the consumer needs to share data further, they can create a new share from their own account, but they cannot re-share the provider's data unless the provider explicitly allows it via GRANT REFERENCE_USAGE.

-- Consumer account: Import the share
CREATE DATABASE sales_shared FROM SHARE provider_account_locator.my_share;

-- Verify the database exists
SHOW DATABASES;

-- Query the shared view
SELECT region, total_sales FROM sales_shared.public.secure_sales_summary WHERE year = 2024;

Creating Listings for the Snowflake Marketplace

Listings are the mechanism to publish data on the Snowflake Marketplace. A listing wraps a share with metadata such as title, description, pricing (if monetized), and terms of use. Listings can be public (visible to all Snowflake users) or private (visible only to specific accounts).

To create a listing: 1. Ensure you have the CREATE LISTING privilege (granted by ACCOUNTADMIN). 2. Create a share with the data you want to list. 3. Use the Snowflake UI or SQL to create the listing. SQL example: CREATE LISTING my_listing FROM SHARE my_share TITLE = 'Sales Analytics' .... 4. Set the listing status to 'PUBLISHED' to make it visible.

Listings support both free and paid data. For paid listings, you need to set up a listing agreement with Snowflake and define pricing. Snowflake handles billing and takes a revenue share.

You can also create listings that require approval (request-based) or are auto-fulfilled. Auto-fulfilled listings allow consumers to access data immediately without provider intervention.

-- Create a listing from an existing share
CREATE LISTING sales_listing
  FROM SHARE my_share
  TITLE = 'Sales Analytics Dataset'
  DESCRIPTION = 'Daily sales data by region and product category.'
  TERMS_OF_USE = 'For internal use only. Not for redistribution.'
  STATUS = 'PUBLISHED';

Managing Access with Secure Views and Row-Level Security

Secure views are the cornerstone of safe data sharing. They allow you to expose only the necessary columns and rows, and they hide the underlying table definitions. Consumers cannot see the view's SQL definition, which protects your intellectual property.

Row-level security can be implemented by using a mapping table that associates consumer accounts with allowed data. For example, you can create a secure view that joins the base table with a permissions table, filtering rows based on the current user's account.

Example: Suppose you have a table sales with a column region. You want each consumer to see only their region. Create a permissions table region_access that maps account locators to regions. Then create a secure view that joins and filters.

Note: The function CURRENT_ACCOUNT() returns the account locator of the consumer running the query. However, in a secure view, this function returns the provider's account locator if the view is defined in the provider's account. To get the consumer's account, use CURRENT_USER() or pass the account as a parameter. A better approach is to use a mapping table that the provider maintains.

-- Provider: Create permissions table
CREATE TABLE region_access (
    account_locator STRING,
    allowed_region STRING
);
INSERT INTO region_access VALUES ('CONSUMER1', 'US'), ('CONSUMER2', 'EU');

-- Create secure view with row-level security
CREATE SECURE VIEW secure_sales AS
SELECT s.*
FROM sales s
JOIN region_access ra ON s.region = ra.allowed_region
WHERE ra.account_locator = CURRENT_ACCOUNT();

-- Grant access to the share
GRANT SELECT ON VIEW secure_sales TO SHARE my_share;

Monetizing Data with Paid Listings

Snowflake Marketplace allows providers to monetize their data by setting a price for their listings. Paid listings can be one-time purchases or subscriptions. Snowflake handles the billing and remits payments to the provider after deducting a marketplace fee.

To create a paid listing: 1. You must have a Snowflake Business Critical or higher edition account. 2. Sign the Snowflake Marketplace Provider Agreement. 3. Create a listing and set the pricing model (e.g., $100 per month per consumer). 4. Snowflake will validate the listing and make it available.

Consumers see the price and terms before accessing the data. They can request access, and the provider can approve or deny. Snowflake tracks usage for billing.

-- Create a paid listing (requires prior agreement with Snowflake)
CREATE LISTING premium_analytics
  FROM SHARE premium_share
  TITLE = 'Premium Sales Analytics'
  DESCRIPTION = 'Real-time sales data with 1-hour latency.'
  PRICING = 'MONTHLY'
  PRICE = 500
  TERMS_OF_USE = 'Subscription required. Data updated hourly.'
  STATUS = 'PUBLISHED';

Best Practices for Production Data Sharing

Implementing data sharing in production requires careful planning to ensure security, reliability, and performance.

1. Use Secure Views: Always share data through secure views rather than base tables. This provides an abstraction layer and allows you to change underlying schemas without breaking consumers.
2. Version Your Shares: When making breaking changes, create a new share (e.g., sales_v2) and gradually migrate consumers. Deprecate old shares after a transition period.
3. Monitor Usage: Use Snowflake's ACCOUNT_USAGE views (e.g., SHARE_USAGE_HISTORY, LISTING_ACCESS_HISTORY) to track who is accessing your data and how often.
4. Set Up Alerts: Configure alerts for when a share is dropped or a listing becomes inactive. Use Snowflake's notification integration or external monitoring.
5. Document Everything: Maintain a data catalog that describes each share, listing, and the underlying views. Include contact information for data owners.
6. Test in a Non-Production Account: Before publishing a listing or updating a share, test the changes in a separate account to avoid impacting consumers.
7. Limit Privileges: Grant only necessary privileges to roles that manage shares and listings. Use custom roles instead of ACCOUNTADMIN.

Performance considerations: Shared queries run on the provider's warehouse. If you have many consumers, consider using a dedicated warehouse for sharing to avoid contention. Also, use clustering on large tables to improve query performance.

-- View share usage history
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.SHARE_USAGE_HISTORY
WHERE SHARE_NAME = 'MY_SHARE'
ORDER BY START_TIME DESC
LIMIT 10;

-- View listing access history
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.LISTING_ACCESS_HISTORY
WHERE LISTING_NAME = 'SALES_LISTING'
ORDER BY ACCESS_TIME DESC
LIMIT 10;

Troubleshooting Common Issues

Even with careful planning, issues can arise. Here are common problems and solutions:

Problem: Consumer gets 'Insufficient privileges' error. - Cause: The share is not granted to the consumer's account, or the consumer's role lacks USAGE on the imported database. - Fix: Verify the share grants: SHOW GRANTS OF SHARE share_name;. Ensure the consumer's role has USAGE on the database: GRANT USAGE ON DATABASE shared_db TO ROLE consumer_role;.

Problem: Listing is not visible in Marketplace. - Cause: The listing status is not PUBLISHED, or the listing is private and the consumer's account is not in the allowed list. - Fix: Check listing status: SHOW LISTINGS;. If private, add the consumer's account: ALTER LISTING listing_name SET ACCOUNTS = 'consumer_account';.

Problem: Query on shared view returns no rows. - Cause: Row-level security filter is too restrictive, or the view references objects that no longer exist. - Fix: Test the view definition in the provider account with the same context. Check if the underlying tables have data.

Problem: Consumer sees stale data. - Cause: The consumer may have created a local copy (e.g., a table) from the shared data. Shared data itself is always live. - Fix: Remind consumers to query the shared database directly, not local copies.

Problem: Provider cannot drop a share because it's referenced by a listing. - Cause: Listings hold a reference to the share. You must drop the listing first. - Fix: DROP LISTING listing_name; then DROP SHARE share_name;.

-- Check if share exists and its grants
SHOW SHARES;
SHOW GRANTS OF SHARE my_share;

-- Check listing status
SHOW LISTINGS;

-- Drop a listing before dropping the share
DROP LISTING sales_listing;
DROP SHARE my_share;