How to Sell on Snowflake Marketplace: ISV Guide

Snowflake Marketplace is where data, native apps, and AI products are listed and sold to Snowflake customers, who buy and consume them inside their own Snowflake account. For a software company it is a way to reach Snowflake’s install base and transact through infrastructure the buyer already trusts — without building order management, metering, or payments yourself.

This guide is the complete provider playbook. It covers the three product types you can list, who is allowed to publish, the full create-and-publish flow through Provider Studio, every pricing and offer model Snowflake supports, how fulfillment and payouts actually work, and where a cross-marketplace platform fits once Snowflake is one of several channels you run.

What Snowflake Marketplace is

Snowflake Marketplace is a catalog inside Snowflake where providers publish listings that consumers install and run in their own account. It is part of the Snowflake Data Cloud, and it is built on Snowflake’s secure data sharing: when a consumer gets a data listing, they query it directly in their own account, without copying or moving the data. That single property — access without a data transfer — is what makes Snowflake Marketplace different from a file feed or an API.

It is also not a hyperscaler procurement marketplace. A Snowflake sale settles inside Snowflake rather than drawing down an AWS or Azure committed-spend agreement, and the buyer consumes what they bought without leaving their Snowflake environment. That distinction drives everything below: because the transaction and the consumption both happen in Snowflake, the provider mechanics — accounts, roles, terms, pricing, fulfillment, payouts — are Snowflake’s own, and they differ from what you set up to sell on AWS, Microsoft, or Google Cloud.

The three things you can list

A Snowflake listing carries one of three product types, and choosing the right one is the first real decision because it changes how the consumer uses what they buy:

A secure share (data product) shares data objects — tables, views, and functions — from your account. The consumer queries them directly in their own account through Snowflake’s data sharing, with no copy and no pipeline to maintain. This is the classic Marketplace listing: curated datasets sold to teams that want the data queryable next to their own.

A Snowflake Native App is an application that runs inside the consumer’s account. Native Apps package logic — stored procedures, UDFs, Streamlit UIs — alongside data, so the consumer installs software that executes on their own Snowflake compute against their own and your shared data. This is how you sell an application, not just a dataset, without asking the customer to move anything out of Snowflake.

A connected app is an external application that processes Snowflake data — a product that lives outside Snowflake but integrates with it, listed on the Marketplace so Snowflake customers can discover and connect to it.

Source: Snowflake, Create and publish a listing.

Who can be a provider

To publish a listing on Snowflake Marketplace you need a full Snowflake account. Trial accounts can share data privately but cannot list on the Marketplace, and Reader Accounts cannot publish at all.

Listing creation requires specific privileges. In practice that means the ACCOUNTADMIN role, or a custom role granted CREATE LISTING, CREATE SHARE, and OWNERSHIP on the data product you are sharing. The organization administrator (ORGADMIN) delegates those privileges, and for auto-fulfillment the ORGADMIN must first delegate auto-fulfillment privileges to ACCOUNTADMIN.

Which legal terms you accept depends on what you publish:

For free private listings only, an administrator accepts the Snowflake Customer-Controlled Data Sharing Functionality Terms (or the combined Provider and Consumer Terms).
For any paid listing or any listing offered on the public Marketplace, the ORGADMIN must accept the Snowflake Provider and Consumer Terms before you can proceed.

Any paid or public listing also requires a provider profile — the public identity (name, description, contact) that represents you in the catalog. Set it up before you start, because you attach it during listing creation.

Source: Snowflake, Use listings as a provider.

Free, trial, and paid: the three access types

When you create a listing you pick one of three access types, and they map to how you want a buyer to start:

Free gives consumers access at no cost. A free Marketplace listing provides instant access to the full published dataset, which makes it the fastest way to build an audience and a reputation before you charge.

Limited trial offers instant, restricted access to a data product on the Marketplace for a trial window of 1 to 90 days, after which the consumer can request unlimited (paid) access. A trial is the on-ramp for a paid data product: the buyer evaluates the real data, scoped down, and converts without leaving the listing.

Paid charges consumers to access or use the listing, and requires a Stripe Express account so Snowflake can pay you. Paid listings are where the pricing models below come into play.

A free trial is optional on private listings and standard for paid listings offered publicly on the Marketplace — Snowflake offers free, trial, and paid as access types rather than mandating a trial, but a public paid tile that gives buyers a way to try before they commit is the common pattern.

Source: Snowflake, About listings.

Public Marketplace vs private listings

Every listing is either public or private, and the difference is who can find it:

A public Marketplace listing is discoverable by any Snowflake customer across the Data Cloud. It needs a provider profile, goes through Snowflake’s approval review, and (if paid) typically offers a trial.

A private listing is shared with named consumers only — you select “Specified Consumers” and add their organization and account names. Private listings publish immediately to those accounts without the Marketplace approval step, which makes them the vehicle for negotiated, one-to-one deals. A private listing can be free or paid; a paid private listing is the Snowflake-native equivalent of a private offer.

You must know a consumer’s account identifier to share any private listing with them.

The create-and-publish flow, step by step

You build listings in Provider Studio. The flow is the same shape for public and private listings, and knowing the stages up front saves a rebuild later:

Create the draft. In Provider Studio, choose Create Listing → Snowflake Marketplace (or Specified Consumers for a private listing). Give it a name, a subtitle, and the provider profile.
Attach the product. Select the type — secure share, Native App, or connected app — and add the data objects or an existing secure share.
Set the access type. Free, limited trial, or paid.
Configure pricing (paid only) — see the next section.
Add the metadata that sells the listing — title and description, custom attributes, a data dictionary of featured objects, “business needs” tags for use cases, and Quick Start examples: sample SQL queries or attached notebooks the consumer can read (view-only) to see the data in action. Add the applicable legal terms.
Set region availability. The default is all regions; you can restrict to custom region groups. Listings offered in regions with deployments in VPS may incur additional fulfillment costs.
Choose a fulfillment method — automatic or manual (below).
Submit for approval (Marketplace listings only). Snowflake reviews the listing; sample SQL is validated, and you must hold ACCOUNTADMIN or OWNERSHIP on the data product. Snowflake emails your Business and Technical contacts to approve or deny.
Publish. Approved Marketplace listings and private listings go live on publish. After the first publication, changes that require approval can publish automatically unless you disable auto-publish in Settings.

Source: Snowflake, Create and publish a listing.

Pricing models in depth

Snowflake supports three pricing structures for paid listings, and they compose with offer terms to cover most commercial shapes:

Usage-based — a monthly access fee plus per-query costs, with optional maximum caps so a consumer’s bill can’t run away. Consumers are billed in arrears in the months where usage occurs. This is the model for data products whose value scales with how much the buyer queries.
Subscription (flat fee) — a fixed amount charged at a specified billing interval for a set term, with optional recurring billing. Consumers are billed upfront. This is the model for predictable, seat- or tier-priced access.
Installment plan — divide the total price into portions the consumer pays one at a time.

On top of the pricing model, an offer specifies the commercial terms: purchase type (self-serve or sales-led), contract duration (a limited-time deal or a recurring subscription), payment structure (single payment or installments), and invoice timing. A self-serve offer is what a buyer accepts off a public tile; a sales-led offer is what your team negotiates for a named account.

One constraint shapes all of this: you cannot remove a pricing plan from a listing once it is added. Model your pricing before you publish, because the plan you ship is effectively permanent for that listing — the same “decide once” discipline that governs a metering dimension on the hyperscaler marketplaces.

Source: Snowflake, Paid listings pricing models.

The monetization gate people forget

Before you can publish a paid listing, Snowflake requires a review. In Snowflake’s words, you “contact your business development partner at Snowflake” or “submit a case with Marketplace Operations,” and that approval is required for listing approval. Monetized listings are available to partners who can show go-to-market readiness, so treat this as a step with a lead time, not a checkbox — engage your Snowflake partner contact before you plan a launch date, not after. The gate is the single most common reason a first paid listing slips its schedule.

Fulfillment: how the data actually reaches the buyer

Because Marketplace listings can be offered across regions and clouds, Snowflake has to get your data to wherever the consumer’s account lives. You choose how:

Automatic (auto-fulfillment) lets Snowflake replicate your data to remote regions automatically after a consumer accepts the listing. You specify a replication frequency and a warehouse to run the replication. Auto-fulfillment is what makes a global public listing practical — you publish once and Snowflake handles delivery to every region you enabled.

Manual fulfillment means you manage delivery yourself, which suits providers who want tight control over where and when data lands.

Region availability and fulfillment interact with cost: offering a listing broadly is a reach decision with an operational tail, so decide your region groups deliberately rather than defaulting to “all regions” for a product that only sells in a few.

How you actually get paid

The consumer is the payer. Two paths move money to you:

If a consumer applies their Snowflake Capacity commitment to the purchase, Snowflake pays the provider.
Otherwise, after the consumer pays, Stripe pays the provider — which is why a paid listing requires a Stripe Express account.

Snowflake’s documentation does not publish a fixed revenue-share percentage for Marketplace transactions, so confirm the current commercial terms with your Snowflake partner contact rather than relying on a third-party figure — provider economics on any marketplace age quickly, and Snowflake is no exception.

Constraints to design around

Two rules are permanent enough to shape your listing design, and both bite providers who move fast:

You cannot remove a pricing plan from a listing once it is added. Get the pricing right before you publish.
You cannot change the share associated with a listing after it is published. Structure the underlying secure share deliberately — the objects you expose at publish time are the objects that listing carries for its life.

Neither is a blocker; both are reasons to treat the first publish of a paid listing as a decision, not a draft.

Metadata is not optional if you want to be found

A Snowflake listing competes for attention in a catalog, and the metadata is what an engine — and a buyer’s search — reads. The sections that matter most:

A data dictionary documenting the featured objects, so a buyer can see the schema before they commit.
Business-needs tags that map the listing to concrete use cases, which is how buyers filter.
Quick Start examples — sample SQL or a notebook — that show the data answering a real question. These are view-only for the consumer and are the closest thing a data listing has to a demo.

Treat these as sales copy, not paperwork: they are the difference between a listing that is discoverable and one that is merely published.

Snowflake Native Apps: selling software, not just data

A secure share sells data; a Snowflake Native App sells software. The Native App Framework lets you package application logic — stored procedures, user-defined functions, and Streamlit interfaces — alongside the data it needs, and distribute the whole thing as a Marketplace listing. The consumer installs the app, and it runs on their own Snowflake compute, against their own data and the data you share, without either party moving anything out of Snowflake.

For an ISV, that changes what you can sell. Instead of shipping a dataset and hoping the customer builds something with it, you ship the application — the transformation, the scoring model, the dashboard — and the customer runs it where the data already sits. The data never leaves their account, which is often the difference between a security review that passes and one that stalls. If your product is logic applied to the customer’s data, a Native App listing is usually the right shape; if it is the data itself, a secure share is.

Snowflake Marketplace vs the hyperscaler marketplaces

If you already sell on AWS, Microsoft, or Google Cloud, it helps to name where Snowflake is the same and where it is not:

What settles. A hyperscaler purchase draws down a committed-spend agreement (an AWS EDP, a Microsoft MACC, a Google commit). A Snowflake purchase settles inside Snowflake, and can draw down a Snowflake Capacity commitment.
What the buyer gets. On a hyperscaler marketplace the buyer usually deploys infrastructure or subscribes to SaaS. On Snowflake the buyer gets data they query in place, or an app that runs in their account — no data movement either way.
Who pays you. Hyperscalers disburse marketplace revenue on their own schedules. Snowflake pays through Stripe, or through Snowflake itself when a Capacity commitment is applied.
The private deal. Every marketplace has a private-offer motion; on Snowflake it is a paid private listing shared to specified consumers.

The practical consequence is that Snowflake is a genuinely separate channel, not a variation on a hyperscaler listing. The listing artifact, the pricing setup, the fulfillment model, and the payout path are all Snowflake’s own — which is exactly why running it alongside five other marketplaces by hand gets expensive.

The mistakes that slow a first listing

The same handful of issues turn a two-week rollout into a two-month one:

Starting the paid listing without the monetization review. The business-development or Marketplace Operations approval is required, and it has a lead time. Start it first.
Finalizing pricing too late. A pricing plan cannot be removed once added, so a rushed plan is a permanent one. Model it before you publish.
Structuring the share carelessly. You cannot change the secure share after publishing, so decide what the listing exposes up front.
Defaulting to all regions. Broad region availability is a cost and an operational decision, not a free reach setting — enable the regions you actually sell in.
Skipping the metadata. A listing with no data dictionary, no business-needs tags, and no quick-start SQL is published but not discoverable. The metadata is the sales copy.

Where Snowflake fits a multi-marketplace GTM

Snowflake is rarely the only marketplace an ISV sells on. Once it sits alongside AWS, Microsoft, Google Cloud, Alibaba Cloud, and Oracle, the cost is not any single listing — it is running six consoles, six pricing models, and six payout reconciliations, each with its own vocabulary for the same events.

That is the problem Suger exists to remove. Suger is a Cloud GTM platform for selling and billing through cloud marketplaces — AWS, Microsoft, Google Cloud, Snowflake, Alibaba Cloud, and Oracle — so listings, private offers, metering and billing, and disbursement reconciliation run from one system instead of six. If you want the deeper cross-cloud picture, the Cloud GTM guide is the pillar, and Snowflake Marketplace for data and AI products covers where Snowflake fits a data-and-AI GTM specifically.

Frequently asked questions

Can you sell on Snowflake Marketplace with a trial account? No. Publishing a Marketplace listing requires a full Snowflake account. Trial accounts can share data privately, and Reader Accounts cannot publish, so plan to list from a full account with ACCOUNTADMIN or a role that has CREATE LISTING, CREATE SHARE, and OWNERSHIP.

What can you list on Snowflake Marketplace? Three product types: a secure share (data queried directly in the consumer’s account), a Snowflake Native App (an application that runs in the consumer’s account), and a connected app (an external product that processes Snowflake data).

What pricing models does Snowflake Marketplace support? Three: usage-based (a monthly access fee plus per-query costs with optional caps, billed in arrears), subscription or flat fee (a fixed amount over a set term, billed upfront), and installment plans that split the total into portions.

How do providers get paid on Snowflake Marketplace? The consumer pays. If they apply a Snowflake Capacity commitment, Snowflake pays the provider; otherwise Stripe pays the provider after the consumer is billed, which is why a paid listing needs a Stripe Express account.

Do you need a free trial to list on Snowflake Marketplace? A free trial is optional for private listings and common for public paid listings, though Snowflake presents free, trial, and paid as options rather than requiring a trial. A limited trial gives instant, restricted access for 1 to 90 days before the consumer requests full access.

What is the difference between a private listing and a Marketplace listing? A private listing is shared with specific consumers by account identifier, publishes immediately, and can be free or paid. A public Marketplace listing is discoverable by any Snowflake customer, needs a provider profile, goes through Snowflake’s approval review, and typically offers a trial if it is paid.

What cannot be changed after publishing a Snowflake listing? Two things are effectively permanent: you cannot remove a pricing plan once it is added, and you cannot change the secure share associated with a listing after it is published. Design both before the first publish.

Takeaways

List from a full account. Trial and Reader accounts cannot publish; you need ACCOUNTADMIN or a role with CREATE LISTING, CREATE SHARE, and OWNERSHIP, and ORGADMIN must accept the Provider and Consumer Terms for anything paid or public.
Pick the product type first — secure share, Native App, or connected app — because it determines how the buyer consumes what they bought.
Choose the access type and the listing’s reach — free, limited trial, or paid; public Marketplace or specified consumers — before you build, because a paid public tile needs a provider profile, usually a trial, and Snowflake’s approval review.
Model pricing and structure the share before the first publish. A pricing plan cannot be removed once added, and the share cannot be changed after publishing.
Know your payout path. Capacity-commitment purchases pay through Snowflake; everything else settles through Stripe Express.
Do not run Snowflake in isolation if you also sell on the hyperscaler marketplaces — the operational cost is the reconciliation across all of them, not any single listing.

Selling on Snowflake is one channel of a larger motion. See how Suger unifies listing, offers, metering, and reconciliation across every marketplace on the Snowflake Marketplace solution page, or book a demo to walk through your own catalog.