Data Clean Rooms, Marketplace, Listings & Native Apps
Day 45 shared data privately between accounts with shares and reader accounts. Today opens that up to public discovery and privacy-preserving collaboration.
| Term | What it sounds like | What it means in Snowflake |
|---|---|---|
| Snowflake Marketplace | An online store for data | A public catalog where providers list data and apps for consumers to query live without copying. |
| Listing | A product page | A share wrapped with metadata such as a title, description, and sample queries, offered to consumers. |
| Native App | An app you install | A package of data plus runnable code that a consumer installs and runs in their own account. |
| Data clean room | A locked lab room | A controlled space where two parties analyze combined data without either seeing the other’s raw rows. |
| Resharing | Forwarding a file | A consumer passing an incoming listing onward to other accounts, allowed only when the provider turns it on. |
The Marketplace and Listings: Public Data Sharing
Marketplace data is live, not a copy
The Snowflake Marketplace is a public catalog of data products from third-party providers. A consumer who gets a data set queries the provider’s data in place. No file is downloaded and no pipeline is built. The data is read-only and stays current as the provider updates it.
This is the same no-data-movement principle from Day 45. A direct share and a Marketplace listing both grant access without copying. The Marketplace adds public discovery and metadata on top of that base.
A listing wraps a share with metadata
A listing attaches presentation details to a share. Those details include a title, a description, sample SQL queries, and provider information. Listings also unlock features a bare share lacks: public reach, cross-region delivery, usage analytics, and paid access.
Two audience choices define how far a listing reaches. A private listing is offered to specific consumer accounts you name. A Marketplace listing is discoverable by anyone browsing the Snowflake Marketplace. A third form, a personalized listing, advertises data publicly but fulfills each consumer with a custom share after a request.
| Audience | Who can access it | Typical use |
|---|---|---|
| Private listing | Only the consumer accounts you name | Sharing with a known partner across regions |
| Marketplace listing | Anyone on the Snowflake Marketplace | Publishing a public data product |
| Personalized listing | Public to view, custom share on request | Tailoring data per consumer after agreement |
Gating paid data with a system function
A listing can be free or paid. A paid listing often offers a free trial that shows a limited subset. Providers control who sees the full data using a single system function inside a secure view.
The function SYSTEM$IS_LISTING_PURCHASED returns TRUE when the querying consumer account has purchased the listing. It returns FALSE for an account that is only trialing. Place the call in a secure view. Paying customers then see full rows, while trial consumers see a restricted set.
-- Provider-side secure view that gates rows by purchase status
CREATE SECURE VIEW gated_v AS
SELECT region_id, region_name, full_metric
FROM provider_data.public.metrics
WHERE SYSTEM$IS_LISTING_PURCHASED('GZT1A2B3C4D'); -- listing global name
-- Trial consumers get FALSE, so they see no rows from this view.This pairs with a lesson from Day 45. A secure view is also the object that shares data across more than one database. The same secure view that hides its definition is the place this paid-data check belongs.
Native Apps: Shipping Logic, Not Just Data
A share exposes data alone. A consumer reads tables and secure views, then runs their own queries. A Native App goes further. It packages data together with runnable code, then installs both in the consumer account.
The code can include stored procedures, user-defined functions, and Streamlit visualizations. The provider builds an application package and publishes it as a listing. The consumer installs the app from the Marketplace or from a private listing, the same delivery path as a data listing.
The provider’s source data does not leave the provider account. The installed app reads that data by reference and runs its logic in the consumer’s account. That split is the exam point: an app distributes behavior, while a plain share distributes only the rows.
| Question | Secure share | Native App |
|---|---|---|
| What is delivered | Data objects only | Data plus application logic |
| Where logic runs | Consumer writes their own queries | Provider’s code runs in the consumer account |
| How it is delivered | Direct share or listing | Listing, public or private |
In training sessions I have run, the cleanest way to remember this is the install step. You install an app. You never install a share. A share gives you a read-only database; an app gives you a working program backed by data.
Data Clean Rooms and Resharing
Analysis without exposing raw rows
A data clean room lets two or more parties analyze combined data without exposing raw rows to each other. Each party keeps its own raw data inside its own account. Neither side can read the other’s underlying records.
The provider defines which analyses are allowed in the clean room. Collaborators run those approved analyses and receive aggregated results. They do not gain row-level access to the data they did not own. A common use is finding the overlap between two customer lists without revealing either list.
This draws a sharp line against ordinary sharing. A share, even through a secure view, grants access to the rows the view returns. A clean room returns analysis results instead of the rows. When a stem asks for collaboration with no raw-data exposure, the answer is the clean room, not the secure view.
Resharing is off until the provider allows it
A consumer who receives a listing cannot pass it onward without the provider’s permission. Resharing must be enabled by the original provider on that listing. With it enabled, a consumer becomes a resharer who builds secure views over the incoming data and shares those onward.
Two limits show up on the exam. Resharing works through listings only, never through direct shares or installed apps. The resharer cannot alter the imported database directly, so they expose the data through new secure views in their own database.
Cheat Sheet
| Concept | What to remember | Exam keyword |
|---|---|---|
| Marketplace data | Live and read-only, queried in place, never copied to the consumer | “no copy, live” |
| Listing | A share plus metadata, with public reach and paid options | “share plus metadata” |
| Listing audience | Private to named accounts, or public on the Marketplace | “private vs Marketplace” |
| Paid-data gating | SYSTEM$IS_LISTING_PURCHASED inside a secure view | “IS_LISTING_PURCHASED” |
| Trial consumer | The function returns FALSE for a trialing account | “FALSE on trial” |
| Native App content | Ships application logic plus data, not data alone | “code and data” |
| App install | Installed and run in the consumer’s own account | “install the app” |
| Data clean room | Analysis on combined data with no raw-row access | “no raw data exposed” |
| Clean room control | The provider defines which analyses may run | “provider sets analyses” |
| Resharing | Works only when the provider enables it, listings only | “provider must enable” |
Exam Tip
Marketplace data is live, never a copy. A stem that says the consumer downloads the data set, or refreshes it through a pipeline, is wrong. The data is read-only and stays current at the source.
For showing paid data only to paying customers, the answer is SYSTEM$IS_LISTING_PURCHASED. The SYSTEM$ALLOWLIST and PRIVATELINK functions are network and connectivity tools. They appear as distractors because they share the SYSTEM$ prefix, so read the function purpose, not just the shape.
Split a Native App from a share by what ships. A share exposes data objects. A Native App installs runnable code, such as stored procedures and functions, that runs in the consumer account. The word install signals an app.
For collaboration with no raw-row exposure, pick the data clean room. A secure view still returns rows to whoever queries it. A clean room returns aggregated analysis results that the provider has approved, not the underlying records.
Hands-On Lab
ACCOUNTADMIN role and the shared lab_xs warehouse. This lab builds the paid-data gating pattern from Concept 1 against a self-contained table, then drops everything.Build a throwaway data set with a sample flag. Some rows are marked as free-sample rows, the rest are full-product rows.
USE ROLE ACCOUNTADMIN;
USE WAREHOUSE lab_xs;
CREATE OR REPLACE DATABASE day46_mkt_db;
CREATE OR REPLACE SCHEMA day46_mkt_db.public;
CREATE OR REPLACE TABLE day46_mkt_db.public.metrics (
region_id INT,
region_name STRING,
full_metric NUMBER,
is_sample BOOLEAN
);
INSERT INTO day46_mkt_db.public.metrics VALUES
(1, 'AMER', 100, TRUE),
(2, 'EMEA', 200, FALSE),
(3, 'APAC', 300, FALSE);Create the gating control and the secure view. The control table stands in for the purchase check so the lab runs on any trial.
-- Stand-in for SYSTEM$IS_LISTING_PURCHASED on a trial account
CREATE OR REPLACE TABLE day46_mkt_db.public.gate (purchased BOOLEAN);
INSERT INTO day46_mkt_db.public.gate VALUES (FALSE);
CREATE OR REPLACE SECURE VIEW day46_mkt_db.public.metrics_v AS
SELECT region_id, region_name, full_metric
FROM day46_mkt_db.public.metrics
WHERE is_sample = TRUE
OR (SELECT purchased FROM day46_mkt_db.public.gate) = TRUE;
-- PRODUCTION FORM of the WHERE clause inside a real listing's secure view:
-- WHERE is_sample = TRUE OR SYSTEM$IS_LISTING_PURCHASED('') Query as a trial consumer, then as a paying consumer. Flip the gate value between the two reads.
-- Trial: gate is FALSE, so only the sample row returns
SELECT * FROM day46_mkt_db.public.metrics_v;
-- Simulate a purchase
UPDATE day46_mkt_db.public.gate SET purchased = TRUE;
-- Paid: all rows return
SELECT * FROM day46_mkt_db.public.metrics_v;Browse the Marketplace in Snowsight. This step is UI only and reads live provider data.
Snowsight -> Data Products -> Marketplace
1. Open a free listing and read its description and sample queries.
2. Note that getting the data creates a read-only shared database.
3. Open the Native Apps area and compare an app listing to a data listing.Cleanup. Drop the throwaway database and suspend the shared warehouse.
DROP DATABASE day46_mkt_db;
ALTER WAREHOUSE lab_xs SUSPEND;
-- Keep lab_xs itself. It is the shared warehouse reused across days.Practice Questions
Options:
A. SYSTEM$ALLOWLIST
B. SYSTEM$ALLOWLIST_PRIVATELINK
C. SYSTEM$AUTHORIZE_PRIVATELINK
D. SYSTEM$IS_LISTING_PURCHASED
Why D: SYSTEM$IS_LISTING_PURCHASED returns TRUE when the querying consumer has purchased the listing. Placed in a secure view, it shows full data to paying customers and a restricted set to trial accounts.
Why not A: SYSTEM$ALLOWLIST returns network hosts and ports for connectivity. It has nothing to do with listing purchase.
Why not B: SYSTEM$ALLOWLIST_PRIVATELINK serves PrivateLink connectivity setup, not share-level data visibility.
Why not C: SYSTEM$AUTHORIZE_PRIVATELINK is also a PrivateLink configuration function. The shared SYSTEM$ prefix is the only thing it has in common with the answer.
Options:
A. It is copied into the consumer account and refreshed by a pipeline
B. It is live and read-only, queried in place with no copy
C. The consumer can update it and push changes back to the provider
D. It arrives as a one-time file export from the provider
Why B: Marketplace data uses Secure Data Sharing. The consumer queries the provider’s data in place, read-only. It stays current with no copy.
Why not A: No copy is made and no pipeline is needed. That is the value of sharing. Re-read Day 45 if missed.
Why not C: Shared data is read-only. A consumer cannot modify it or write anything back.
Why not D: There is no file export. The data is accessed live through the share.
Options:
A. A private listing is offered to specific named accounts; a Marketplace listing is publicly discoverable
B. A private listing copies data, while a Marketplace listing does not
C. A private listing works only on Business Critical Edition
D. A Marketplace listing cannot include sample queries or metadata
Why A: The audience is the difference. A private listing reaches only the consumer accounts the provider names. A Marketplace listing is discoverable by anyone on the Marketplace.
Why not B: Neither listing copies data. Both share access in place, like every share.
Why not C: Listings are not gated to one edition. The split is about audience, not edition.
Why not D: Metadata and sample queries are the point of a listing. Public listings carry more metadata, not less.
Options:
A. Application logic such as stored procedures and functions, installed in the consumer account
B. A copy of the provider’s raw data moved into the consumer account
C. Write access for the consumer to update the provider’s tables
D. Automatic cross-region failover of the shared data
Why A: A Native App packages data with runnable code. The consumer installs the app. The provider’s logic then runs in the consumer account.
Why not B: The provider’s source data stays in the provider account. The app reads it by reference, with no copy.
Why not C: Shared data and app-backed data are read-only. No write access is granted to the consumer.
Why not D: Failover is a replication feature for disaster recovery. It is not what defines a Native App. Re-read Day 45 if missed.
Options:
A. Each party keeps its own raw data and neither side reads the other’s rows
B. Collaborators receive aggregated analysis results rather than row-level access
C. A clean room copies both parties’ raw data into one shared database
D. The consumer may freely query every raw row the provider contributes
E. A clean room is just another name for a secure view
Why A and B: A clean room lets parties analyze combined data without exposing raw rows. Each side keeps its own data. Collaborators get approved aggregated results, not the underlying records.
Why not C: No raw data is merged into a shared copy. That would defeat the privacy goal of a clean room.
Why not D: Free access to raw rows is exactly what a clean room prevents. The provider controls which analyses run.
Why not E: A secure view returns rows to whoever queries it. A clean room returns analysis results, so the two are not the same.
Snowflake Documentation
Official docs for today’s topics. The exam pulls directly from these.
Today you learned: how Snowflake shares data publicly and how parties collaborate without exposing raw rows. The Snowflake Marketplace serves live, read-only data that is queried in place with no copy. A listing wraps a share with metadata and adds public reach, cross-region delivery, and paid access. A private listing targets named accounts, while a Marketplace listing is publicly discoverable. Providers gate paid data with SYSTEM$IS_LISTING_PURCHASED inside a secure view. The function returns FALSE for trial consumers. A Native App ships application logic together with data. The consumer installs and runs it in their own account. A data clean room lets parties analyze combined data and return only approved aggregated results, with no raw-row access. Resharing works only when the provider enables it. It runs through listings only.
Key takeaway: separate access from analysis. Sharing and listings grant access to rows in place. A clean room grants analysis results without the rows. For paid-data visibility, the one function to know is SYSTEM$IS_LISTING_PURCHASED, used in a secure view.
Tomorrow (Day 47): the Week 7 recap and a mixed Domain 5 quiz. You revisit Time Travel versus Fail-safe, cloning, and replication and failover. You also revisit sharing, reader accounts, and today’s Marketplace, listings, Native Apps, and clean rooms. Domain 5 is a small slice of the exam, so the recap targets the boundaries that earn easy points.
