The Perfect Pipeline No One Could Use

Three delivery decisions your team needs to make before the first model runs.

I once spent three weeks building a clean, tested Snowflake pipeline for a risk team. Latency under five minutes. Data quality checks passing. It was beautiful. Then the risk analyst asked me to “send the file.” He had no idea Snowflake existed. So I zipped a CSV and emailed it.

That was the day I learned the pipeline was never the finish line. Delivery is.

Most data engineers treat sharing as an afterthought — a file export, a link, a page with credentials taped to it. But Snowflake has an entire delivery stack: Direct Shares, Marketplace listings, Streamlit apps, and Native Applications. Choosing the wrong layer doesn’t just add friction. It recreates the exact data silos you built the pipeline to eliminate. So once the pipeline is done, what’s the right way to actually deliver the data product?

1. The Marketplace Is Your Pipeline’s Last Mile

Here’s what I should have done instead of emailing that CSV: publish a listing.

A listing is an enhanced form of Snowflake’s Secure Data Sharing. It eliminates the need to manually extract, copy, or move files to external storage. Instead of a static export that’s stale the moment it lands in someone’s inbox, the consumer accesses live, ready-to-query data directly. As the documentation puts it: “As a data consumer, you can reduce the data transformations you need to perform because the data stays in Snowflake, making it easy to join datasets shared with you with your own data.”

You get two flavors. Use a private listing to share with specific Snowflake accounts in any region — ideal for existing business partners where payment is handled off-platform. Use a public Marketplace listing to market a data product globally, reach many consumers at once, charge for access through built-in pricing, and attach rich metadata like descriptions and sample SQL queries.

The gotcha: you cannot change a listing’s type after you create it. A limited trial listing can never become a paid listing. And paid listings are restricted by geography — available only to providers and consumers in specific regions. Decide your listing strategy before you publish, not after a consumer asks for more.

2. Streamlit vs. Native Apps: Same Logo, Completely Different Scope

Now move the CSV story one step forward. Suppose that risk analyst hadn’t wanted to read a table — he’d wanted to run scenarios against it. I would have reached for Streamlit in Snowflake: interactive interfaces in pure Python, no HTML or CSS required, built fast and shared with teammates.

But here’s the catch that bit me later: a Streamlit in Snowflake app is typically bound to a single account. If that analyst had been at a different company, my app would never have reached him. A year later I learned that lesson the expensive way: a dashboard I had shipped as a Streamlit app got requested by an external partner, and I had to rebuild the whole thing as a Native App from scratch — roughly three weeks of work I could have avoided by asking one question up front.

That boundary is exactly where Snowflake Native Applications begin.

A Native App is a fully contained data product, bundled into an application package and distributed through a listing. It installs and runs entirely within the consumer’s own Snowflake account, powered by their compute and their data. In Snowflake’s words: “Streamlit in Snowflake apps are typically bound to accounts… Snowflake Native applications run in consumer accounts, and consumers power the application with their account’s data and compute resources.” Native Apps can even embed Streamlit interfaces or run containerized workloads through Snowpark Container Services.

The gotcha: when a consumer installs your Native App, it gets zero automatic access to their data. They must explicitly grant the app permission to touch specific objects. The app also can’t make external API calls outside the Snowflake environment by default, and it has to clear a security review before distribution. Powerful, but never plug-and-play.

3. The Real Miss: Not Defining the Consumer First

The CSV wasn’t actually my mistake. My mistake was choosing a delivery method before I’d defined who I was delivering to.

Every one of these vehicles maps cleanly to a consumer type — but only once you answer three questions: who is this for, where do they live, and what are they allowed to see?

Use this quick map to self-diagnose:

• Direct Share — internal or same-region consumers who just need read-only tables and views. Low maintenance, but geographically limited.
• Data Exchange — a private, invited group where you control who publishes and who consumes.
• Declarative Native App — a partner who needs data alongside code objects (notebooks, Streamlit, UDFs), delivered through a simple YAML manifest with role-based access control (RBAC).
• Full Native App — an external consumer running complex business logic or containers inside their own account. Highest maintenance, security review required.

The constraint that catches people: Direct Shares are geographically limited. If you need to share cross-region or cross-cloud without manual replication, you must use a listing instead. As the sources note: “Listings let you share data with people in any Snowflake region, across clouds, without performing manual replication tasks.”

The gotcha: the sources frame this as a business decision, not a technical one — “Choosing the right data product is determined by your business needs. Do you want to get started quickly? Do you need an app with advanced features?” Engineers approach it backwards almost every time, picking the most powerful tool and then hunting for a consumer to justify it.

The Answer

The right delivery method is not the most powerful one available. It’s the one that matches how your consumer works, where they live, and what they’re permitted to see. Direct Share for the teammate next door. A listing for the partner across the cloud. Streamlit for the analyst who needs to poke at the data. A Native App for the customer who needs to run your logic on their own.

If you haven’t mapped your pipeline’s output to a specific consumer persona before picking the delivery method, you’re still emailing CSVs. Just with extra steps.

So start there on Monday. Before you touch the delivery layer, ask the one stakeholder who requested the data three questions: who else needs this, what Snowflake region or cloud do they sit in, and which objects are they actually allowed to see? Write the answers down, then match them to the quick map above. Once you know the consumer, the right delivery method usually picks itself — and you can open Snowflake’s data-sharing docs already knowing which page you need.

I’ve made all three of these mistakes in the same quarter. Which one have you hit? Drop a comment.

[embed]Unlocking the Power of JSON in Supabase: A Step-by-Step Guide Effortlessly Manage Unstructured Data with Supabase’s JSON Superpowersdaoleo.medium.com