What is a Snowflake Marketplace listing, and how does it differ from a direct share?
answer
- the same share underneath both
- one is point-to-point, one is a catalogue
- discovery and request-and-approve flows
- private, public, or an invitation-only hub
- only one of them can leave the region
basics
~20 sA listing wraps a share in a published product: title, description, usage terms, discovery and access requests. A direct share is a private grant to accounts you name; a listing lets consumers find and request the data themselves.
solid answer
~40 sUnderneath, both deliver the same thing — a read-only database created from a share, with no data copied for same-region consumers. A **direct share** is point-to-point: you add specific account identifiers and the consumer imports it. A **listing** adds a product layer on top: metadata, sample queries, usage terms and a request-and-approve flow, so consumers discover the data instead of you provisioning each one. Listings can be **private**, targeted at named accounts, or published publicly on the **Snowflake Marketplace**, free or paid or gated behind provider approval. A **data exchange** is the middle ground: an invitation-only hub the provider administers for a defined group, such as an enterprise's own business units or an industry consortium. Listings also unlock cross-region and cross-cloud fulfillment, which a direct share cannot do at all.
go deeper
Know that the Marketplace exists and that taking a listing gives you a read-only database in your own account, most often as a consumer pulling in a reference dataset.
Explain that a listing is a share with a product wrapper — discovery, terms, request-and-approve — and distinguish private listings, public Marketplace listings and an invitation-only data exchange.
Be able to say why you would move from direct shares to listings: self-serve onboarding, usage telemetry, and cross-region or cross-cloud fulfillment that a direct share cannot do.
Treat this as a distribution decision — whether your data is an internal grant or a product with a catalogue entry, terms and a regional footprint whose fulfillment cost you are choosing to absorb.
## The same plumbing, a different front door Every one of these mechanisms ends with the consumer running a query against a read-only database backed by a share. The differences are entirely in discovery, packaging and fulfillment. **Direct share.** The provider creates a share, grants objects to it, and names consumer accounts explicitly with `ALTER SHARE ... ADD ACCOUNTS`. Nothing is discoverable; the provider must know each consumer's account identifier and act for every one of them. This is the right shape for a handful of known partners and for internal sharing between accounts you control. **Listing.** The provider publishes the share as a product with a title, description, category, sample queries and usage terms. Consumers browse or search, and either get access instantly or submit a request the provider approves. Access becomes self-serve, and onboarding stops being a ticket for your team. Listings may be: - **Private** — visible only to consumer accounts the provider targets. Effectively a direct share with a product wrapper and, importantly, with the cross-region fulfillment machinery available. - **Public on the Marketplace** — visible to Snowflake customers generally, offered free, for a fee, or on a request-and-approve basis where the provider vets each consumer before granting. **Data exchange.** A private, invitation-only hub the provider administers, inside which members publish listings to each other. The archetypal uses are an enterprise sharing curated datasets between its own business units and regions without a public presence, and a consortium of companies exchanging data among vetted members. ## What the listing layer actually buys you 1. **Discovery.** Consumers find the data rather than emailing you. For a company whose data is a product, this is the difference between a sales motion and a catalogue. 2. **Onboarding without provisioning.** No collecting account identifiers, no `ALTER SHARE` per customer. Access requests and approvals replace manual grants. 3. **Cross-region and cross-cloud reach.** A direct share cannot leave its region. Listings support auto-fulfillment, where Snowflake provisions and maintains the remote copy when a consumer in another region or cloud takes the listing. This is often the real reason to move from shares to listings, independent of any commercial ambition. 4. **Commercial terms.** Paid listings let the data itself be the product, with Snowflake handling the transaction, instead of you invoicing separately and managing entitlement by hand. 5. **Usage visibility.** Providers get telemetry about consumption of their listings, which direct sharing does not surface in the same way — useful for knowing which datasets justify their maintenance. ## What does not change - The consumer still pays for their own compute; the provider still pays storage. Paid listings add a separate commercial charge on top of that model, not instead of it. - The shared database is still read-only: no DML, no cloning, no re-sharing onward. - Row- and column-level restriction is still done the same way — secure views over an entitlement table, or row access policies. A listing does not filter anything for you. - Cross-region fulfillment still means a real copy, so the consumer reads a maintained replica rather than live data, and the provider pays for the storage and transfer. ## Choosing between them Use a **direct share** when the consumers are few, known and internal-ish, and everyone is in your region. Use a **private listing** when you want self-serve onboarding, a documented product surface, or cross-region reach for named partners. Use a **public Marketplace listing** when the data is a product you want strangers to find, or when you want to consume someone else's data — most engineers meet the Marketplace first as a consumer, pulling in a reference dataset such as weather or holiday calendars in a couple of clicks. Use a **data exchange** when a defined group needs a private hub with several publishers rather than one provider fanning out to many consumers. ## Interview weight This is differentiator material, not a screening question. Nobody fails for not knowing the listing taxonomy. What is worth having ready is the one-sentence distinction — same share underneath, different discovery, packaging and fulfillment — plus the fact that listings, not direct shares, are how data reaches another region or cloud. Candidates who claim the Marketplace is a separate copy-based product, or that it changes who pays for compute, are revealing they have only read the marketing page.
- Does publishing data as a Marketplace listing change who pays for the consumer's queries?No. The consumer still runs queries on their own warehouse and pays their own compute; the provider still pays storage for the source data. A paid listing adds a commercial charge for access on top of that model. The only place the provider picks up extra infrastructure cost is cross-region fulfillment, where they pay for the remote copy and its transfer.
- When is a data exchange the right choice over a set of private listings?When several parties in a defined group both publish and consume — an enterprise's business units, or an industry consortium. The exchange gives them a private, invitation-only hub with membership administration, rather than one provider fanning out individual listings to a list of accounts it maintains by hand.
A direct share is handing a colleague a key; a listing is putting the product on a shelf with a label, a price and a returns policy. The thing behind the door is identical.
saying these in an interview costs you the question
- Says the Marketplace physically copies data to consumers by default
- Thinks a listing changes who pays for query compute
- Believes a direct share can reach another region
- Assumes all Marketplace listings are free and public
- Expects the listing layer to apply row-level filtering for you