TL;DR
Streamlit in Snowflake lets data and engineering teams build interactive apps directly on their Snowflake data, with zero external servers, zero data movement, and zero separate auth layers. Apps run inside the platform, inherit Snowflake’s RBAC and governance, and connect natively to Cortex AI and Snowpark. The tradeoffs are real but narrow: access requires a Snowflake account, custom components are unavailable, and single queries cap at 16 MB. For most internal enterprise use cases, the architecture holds up well in production.
Data apps used to require a separate deployment environment, a dedicated backend team, and a pipeline to move data out of the warehouse before it could be visualized. Streamlit in Snowflake collapses all of that. Apps run natively inside the platform, against the same data, using the same governance model, with no infrastructure to manage.
Snowflake acquired Streamlit in March 2022 for approximately $800 million with a clear goal: let teams build and share data applications without moving data outside Snowflake. Three years later, the integration is production-grade and in active use at scale across enterprise environments.
This guide covers what Streamlit in Snowflake (SiS) actually does, how to set it up, where it fits in a modern data stack, and what experienced teams watch for before deploying it at scale.
Key Takeaways Streamlit in Snowflake, widely abbreviated as SiS, runs apps as native Snowflake objects. Compute, storage, and access control stay inside the platform with no external infrastructure required. Two runtime environments exist, warehouse and container, each with different tradeoffs for library flexibility, performance, and cost. Role-based access control (RBAC) governs who sees which app, using the same permission model already in place for Snowflake tables and schemas. Cortex AI integration lets SiS apps call LLMs, run sentiment analysis, and query data in natural language without leaving the Snowflake environment. Snowflake Summit 2026 promoted Workspaces, Next-Gen Runtime, and Business User Access to GA, bringing meaningful changes for enterprise deployment and non-technical adoption. Known constraints include a 16 MB per-query data limit, a Snowflake account required for app access, and no support for custom Streamlit components.
From Data Architecture to AI-Ready Analytics Kanerika’s Snowflake practice covers the full stack, pipelines, governance, Cortex AI, and application delivery.
Explore Our Snowflake Services →
What Streamlit in Snowflake Is and How It Works Streamlit is an open-source Python framework that turns scripts into shareable web apps. It handles the web layer so developers write Python from top to bottom and the UI updates automatically as users interact with widgets. Snowflake integrated it natively into the platform, meaning SiS apps run as first-class Snowflake objects rather than as external services that connect to Snowflake via API.
The practical difference matters in enterprise settings. App code lives in a Snowflake stage, executes on Snowflake compute, and connects to data through an active session that is already authenticated. Data never leaves Snowflake to reach the app. The app runs where the data lives, which eliminates an entire category of governance and security complexity that appears when teams host Streamlit externally. For teams evaluating Snowflake’s capabilities more broadly, Kanerika’s Snowflake architecture guide covers how storage, compute, and cloud services interact.
1. The Two Runtime Environments SiS offers two distinct runtime choices, and picking the right one early avoids rework later. The warehouse runtime runs apps in a personal instance per viewer, using Python 3.9–3.11, and draws packages from Snowflake’s curated Anaconda channel via an environment.yml file. It is simpler to configure and works well for most internal dashboards and data tools.
The container runtime uses Snowpark Container Services. It supports any Python library, allows public URL assignment, and suits workloads that need packages outside Snowflake’s Anaconda channel or require cross-session shared state. Setup complexity is higher: container runtime requires a compute pool, is unavailable on trial accounts, and adds configuration overhead. For most enterprise internal apps, the warehouse runtime is the right default.
Table 1: Warehouse Runtime vs Container Runtime
Factor Warehouse Runtime Container Runtime Python versions 3.9, 3.10, 3.11 3.11 (system default) Package source Snowflake Anaconda channel Any pip-installable library Cross-session state Per-viewer personal instance Supported Public URL No (Snowsight only) Yes Setup complexity Low High (compute pool required) Trial account support Yes No Best for Internal dashboards, data tools External-facing or full-stack apps
Misidentifying which runtime a workload needs is one of the more common sources of rework in enterprise SiS deployments. Getting this decision right at the start saves significant effort later.
2. How the Session Model Works When a user opens a SiS app, Snowflake creates an authenticated session automatically. The app code calls get_active_session() from snowflake.snowpark.context and gets a live session object with no manual credential handling. That session runs under the owner’s privileges by default, a design choice that simplifies sharing but requires careful RBAC setup before granting access to sensitive datasets.
Queries run against Snowflake tables, views, and stored procedures directly, with no ETL step to move data into the app layer. This keeps data current and eliminates the latency gap that appears when external BI tools cache query results on their own infrastructure. The Snowflake data engineering layer feeding these apps matters too. SiS surfaces data reliably only when the pipelines behind it are well structured.
Why Data Teams Are Building Apps Inside Snowflake The primary reason teams choose SiS over external hosting is architectural. When a Streamlit app runs outside Snowflake, it needs credentials to query Snowflake, a compute environment to run Python, a hosting service to serve the app, and a separate access control layer to decide who can open it. Each of those components adds cost, maintenance overhead, and a potential security exposure point.
SiS removes all four. The platform handles compute, storage, hosting, and access control as a single managed service. For organizations already on Snowflake, adding a SiS app layer introduces no new infrastructure. It uses what is already there.
1. The Problem with External BI Tools Traditional BI tools like Tableau and Power BI connect to Snowflake via JDBC or ODBC and pull data into their own caching layer. That architecture works well for dashboards built on stable data with predictable refresh schedules. It creates problems for teams that need real-time interactivity, write-back functionality, or integration with Python ML models that live inside Snowflake.
Streamlit handles interactive widgets, dynamic filtering, and write-back to Snowflake tables natively. A data engineer can build a tool that lets a business analyst set a forecast parameter, write it back to a Snowflake table, and trigger a downstream pipeline, all in a single session with no external API call. That pattern is difficult or impossible to replicate in a standard BI tool without significant custom development.
2. Where SiS Fits in the Modern Data Stack SiS sits at the application layer of the Snowflake stack, above the data engineering and transformation tiers. Data lands in Snowflake via data pipelines . Snowpark handles transformations and ML model training. Snowflake Cortex AI provides LLM inference. Streamlit surfaces all of it as an interactive interface for analysts, business users, or operational teams who need to interact with the output rather than the code.
That positioning makes SiS most valuable in organizations where data engineering and analytics teams already operate on Snowflake and need to deliver tools to non-technical stakeholders quickly. Building a standalone dashboard in Tableau takes weeks when data model changes are frequent. A SiS app on the same data can be iterated in hours and shared via RBAC-controlled URL.
Setting Up Streamlit in Snowflake Step by Step The fastest path to a running SiS app goes through Snowsight, Snowflake’s web UI. The setup process takes under five minutes for a basic app, though production deployments require more careful privilege configuration upfront.
1. Role and Privilege Configuration Before creating a SiS app, the creating role needs USAGE on the target database and schema, CREATE STREAMLIT and CREATE STAGE privileges on the schema, and USAGE on at least one warehouse. These must be granted explicitly; they are absent from standard role defaults. For teams sharing apps across roles, the owner role that created the app controls which other roles can view it. SiS runs as owner’s rights only; caller’s rights are currently unavailable.
The privilege setup is where most first-time deployments stall. Running under ACCOUNTADMIN during initial setup confirms the app itself works before debugging role configuration separately. Kanerika’s Snowflake security guide covers the full RBAC model, network policies, and encryption layers that govern SiS apps alongside your data.
2. Creating Your First App in Snowsight In Snowsight, navigate to Projects, then Streamlit, then select the plus icon to create a new app. Snowflake prompts for an app name, a warehouse to run it on, and a database and schema for the app’s stage files. Selecting Create opens a split-screen editor with a code panel on the left and a live preview on the right. The default starter code runs immediately and confirms the environment is working before any custom code is added.
For the warehouse runtime, starting with an X-Small warehouse covers most development and low-traffic production use. A dedicated warehouse for the app makes cost attribution straightforward. Snowflake’s usage view shows compute spend by warehouse, so a shared warehouse mixes app costs with other workload costs. Running a dedicated warehouse with auto-suspend set to one minute keeps idle costs low while making cost monitoring clean. Kanerika’s Snowflake cost optimization guide goes deeper on warehouse sizing and spend controls.
3. Connecting to Snowflake Data via Snowpark Inside a SiS app, the Snowpark connection is pre-authenticated. The standard pattern is a try/except block that calls get_active_session() inside SiS and falls back to Session.builder.configs() for local development. This pattern lets the same app code run in Snowsight and locally without modification, which is useful when iterating quickly.
Data is queried via the session object using either SQL strings or the Snowpark DataFrame API. SQL is often simpler for straightforward lookups. The DataFrame API is useful when transformations need to run server-side before results reach the app layer. Pushing computation to Snowflake rather than pulling raw data into the Python process keeps result sizes under the 16 MB per-query limit.
Deploying and Sharing SiS Apps Snowsight sharing is the default path for internal apps. Once an app is created, the owner role grants VIEW or USAGE to other roles using the same GRANT syntax used for tables and views. Users with the granted role see the app under their Projects tab in Snowsight and open it by clicking the app name. There is no separate user management system. Access follows the existing Snowflake role hierarchy.
1. Sharing Apps with Role-Based Access Control Sharing via RBAC keeps access governance consistent across data and apps. A role that can query a table can be granted access to an app that queries that table, and revoking the role removes access to both. That consistency matters in regulated industries where access reviews need to account for every path to sensitive data, including application interfaces and direct SQL access.
One constraint worth flagging explicitly: SiS apps require a Snowflake account for access. Users outside the organization’s Snowflake account are unable to open a SiS app, even via a direct URL. Organizations that need to serve apps to external users should host Streamlit outside SiS or use the Snowflake Native App Framework, which packages apps for distribution to other Snowflake accounts.
2. CI/CD Deployment with Snowflake CLI For teams that version-control app code in Git, the Snowflake CLI (snow streamlit deploy) provides a programmatic deployment path. Snowflake CLI 3.14.0 and later uses the updated CREATE STREAMLIT syntax with FROM source_location. The deploy command uploads local files to a stage and creates or replaces the Streamlit object in the target database and schema.
GitHub Actions integration is straightforward. A workflow file triggers on push to main, installs the Snowflake CLI, writes the connection config from repository secrets, and runs snow streamlit deploy --replace. That setup gives teams a simple CI/CD pipeline without a dedicated deployment service. For production environments, adding a staging branch and environment-specific connection configs keeps development and production deployments separate. Snowflake’s official deployment documentation covers the full CI/CD configuration options.
Enterprise Use Cases Beyond the Dashboard Generic SiS tutorials focus on dashboards because dashboards are the simplest case. Enterprise teams get more value from patterns that use the full Snowflake stack: Cortex AI for language tasks, write-back for operational workflows, and internal tools that replace point solutions with purpose-built apps on governed data.
1. AI-Powered Apps with Snowflake Cortex Snowflake Cortex AI provides access to LLMs including models from Anthropic, OpenAI, Meta, and Mistral, hosted inside Snowflake’s infrastructure. SiS apps call Cortex functions using snowflake.cortex.Complete() via SQL or the Snowpark Python API. Because inference runs inside Snowflake, sensitive data can be passed to an LLM without transmitting it to a third-party API endpoint, a significant consideration for healthcare, financial services, and legal applications.
Common Cortex-powered SiS patterns include document Q&A apps that query Cortex Search over internal knowledge bases, query analysis tools that explain execution plans in plain language, and NLP dashboards that run sentiment analysis on customer feedback stored in Snowflake tables. Kanerika’s Snowflake Cortex guide covers the AI function library in depth, including how Cortex Analyst and Cortex Search integrate into app workflows. The Cortex + Streamlit developer guides from Snowflake cover the connection patterns in detail, including streaming responses for chat interfaces.
2. Write-Back Applications Write-back is one of the clearest differentiators between SiS and traditional BI tools. A Streamlit app can read data from a Snowflake table, display it for user interaction, accept input through widgets, and write the result back to a Snowflake table in the same session. That pattern supports planning workflows, forecast parameter entry, data quality annotation, and operational approval queues, all without a separate application tier or API layer.
The st.data_editor component handles editable grid interfaces for row-level input. The session object handles the write, running a standard INSERT or MERGE against the target table. Access control on the write path uses the same owner’s-rights model. The app writes under the creating role’s permissions, so data governance on the target table is enforced through standard Snowflake RBAC.
3. Internal Operational Tools for Business Teams Beyond analytics, SiS works well for operational tools that give non-technical users a UI over Snowflake workflows. Common examples include tools that let a business analyst trigger a stored procedure with configurable parameters, interfaces for approving or rejecting records that feed downstream pipelines, and monitoring dashboards with alert configuration built into the app itself.
A tool that calls a stored procedure requires no credential exposure to the user and no separate authentication layer. The session handles it. As a Snowflake Select Tier Partner , Kanerika’s implementation teams build these operational tool patterns regularly for enterprise clients across manufacturing, logistics, and financial services.
Source: Snowflake Developers Snowflake Summit 2026 Updates for Streamlit Snowflake’s June 2026 Summit moved several SiS features from preview to general availability, and the changes affect how enterprise teams should plan deployments today. Over 1 million developers build with Streamlit in Snowflake every month, according to Snowflake’s Summit announcement , a figure that reflects how far adoption has grown since the 2022 acquisition.
Three GA releases from Summit 2026 are directly relevant to enterprise SiS adoption:
Workspaces (GA): A browser-based development environment with Git integration, AI-assisted coding, and isolated experimental spaces that leave production apps untouched. Teams can iterate on new features without affecting the live version.Next-Gen Runtime (GA): Faster cold start times, same-day Python library availability, and full parity with the open-source Python ecosystem. Library version constraints that previously forced workarounds in the warehouse runtime are now significantly reduced.Business User Access (GA): SSO support for non-technical stakeholders. Business users can open SiS apps directly using their existing identity provider credentials, with no separate Snowflake login step required. This removes the primary adoption barrier for internal app rollouts at scale.
The Business User Access release in particular changes the deployment calculus for enterprise internal tools. Previously, rolling a SiS app out to a finance or operations team meant provisioning Snowflake user accounts for people who would never write a SQL query, a governance overhead that led many teams to host Streamlit externally instead. SSO integration removes that step entirely.
Performance, Cost, and Governance Decisions SiS performance depends on warehouse sizing, caching strategy, and how data loading is structured within the app. Getting these right matters more for high-traffic apps than for developer tools used by small teams. Broader Snowflake cost optimization principles apply here too. Warehouse rightsizing and auto-suspend discipline affect SiS spend just as they affect query workloads.
1. Warehouse Sizing and Cost Attribution Warehouse runtime apps run on a virtual warehouse, and compute costs accrue while sessions are active. For apps with unpredictable usage patterns, auto-suspend set to one minute limits idle spend. A dedicated warehouse per app or per app group makes cost attribution straightforward in Snowflake’s usage dashboards. Running multiple apps on a shared warehouse reduces cost visibility and makes it harder to identify which app is driving compute spend during usage spikes.
Warehouse size should match the app’s heaviest query, not its average query. An X-Small warehouse handles most internal dashboard use cases. Apps that run heavy aggregations on large tables benefit from upgrading to Small or Medium during active use and suspending otherwise. The per-second billing model means sizing up temporarily is inexpensive if auto-suspend is configured correctly.
2. Caching and Data Loading Patterns Streamlit reruns the full app script on every widget interaction by default. Without caching, every slider adjustment or filter change triggers a new query against Snowflake. The @st.cache_data decorator caches query results between reruns and dramatically reduces warehouse usage for apps where underlying data stays stable between interactions. Cached results persist across user sessions, so this pattern also improves performance for multiple concurrent users accessing the same app.
Progressive data loading matters for apps that display large result sets. Loading only what the user needs in a given view, rather than pulling the full dataset and filtering in Python, keeps result payloads under the 16 MB per-query limit and reduces latency. Designing around this constraint from the start avoids the rewrite that comes when a dashboard that worked fine during development starts timing out in production with full data volumes.
The patterns above address the most common performance problems teams encounter after moving from a development environment with small data to a production environment with full volume.
Table 2: Performance Patterns for Enterprise SiS Apps
Issue Cause Fix High compute costs Warehouse running while idle Auto-suspend set to 60 seconds; dedicated warehouse per app Slow widget response Full script re-runs on every interaction @st.cache_data on data fetch functions16 MB query limit hit Full dataset pulled before filtering Push filters into SQL; use Snowpark DataFrame operations server-side Cold start latency Warehouse suspended; restarts on first access Keep warehouse running during business hours; pre-warm with a scheduled query Unclear cost attribution App shares a warehouse with other workloads Dedicated warehouse per app or app group
Deployment Realities of Streamlit in Snowflake for Enterprise Teams SiS covers most enterprise internal app use cases well, but four constraints are worth explicit planning before committing to it as a deployment target. Each one has led teams to rearchitect after the fact when caught too late.
Table 3: Streamlit in Snowflake vs Standalone Streamlit
Factor Streamlit in Snowflake (SiS) Standalone Streamlit Infrastructure management None (fully managed) Self-managed or cloud-hosted Access model Snowflake account required Any auth method Custom components Unavailable Supported Caller’s rights Unavailable (owner’s rights only) N/A Single query data limit 16 MB No platform limit Library availability Snowflake Anaconda channel (warehouse runtime) Any pip package Cortex AI access Native, no external API Requires Snowflake connector + credentials Cost model Snowflake compute credits Separate hosting and compute costs
The access model constraint matters most for apps intended for external users. If the app audience extends beyond employees with Snowflake accounts, standalone Streamlit or the Native App Framework is the right architectural choice. For internal enterprise apps, SiS’s managed infrastructure, native Cortex access, and RBAC alignment outweigh the constraints for most use cases. Snowflake’s governance layer, covered in depth in Kanerika’s Snowflake Horizon Catalog guide , extends to SiS apps and gives data teams unified visibility over both data assets and the apps that consume them.
Snowflake Data Engineering: Building Production Pipelines That Last A practical guide to Snowflake data engineering: Snowpark, ELT, Streams, Dynamic Tables, dbt, and Snowpipe for production pipelines.
Learn More
Snowflake Implementation at Enterprise Scale with Kanerika Kanerika is a Snowflake Select Tier Partner with over a decade of enterprise delivery across data engineering , AI implementation , and platform governance. With 100+ enterprise clients and a 98% retention rate, Kanerika works across Snowflake, Microsoft Fabric, and Databricks, which means architecture recommendations are shaped by cross-platform delivery experience rather than a single-vendor playbook.
On Snowflake specifically, Kanerika’s practice covers the full stack: data pipeline design, Cortex AI integration, RBAC configuration, warehouse cost management, and migration execution via FLIP, Kanerika’s automation platform. For enterprises evaluating Snowflake as a foundation for internal data apps and analytics, Kanerika’s starting point is always data architecture and governance. Clean, governed data is what makes any application layer reliable at scale, whether that is a Streamlit app, a BI dashboard, or an AI agent built on Cortex.
Source: Snowflake Developers The Challenge A global tech consulting firm ran distributed operations across multiple regional systems. Reporting depended on manual reconciliation. Data from each region had to be pulled together by hand before any cross-functional view was possible. Month-end close was the earliest most teams saw operational data, making intra-month decisions reactive rather than data-driven. The firm needed a governed, unified data layer that could support real-time visibility and serve as a foundation for future application development.
The Solution Kanerika migrated the firm’s reporting infrastructure to Snowflake and rebuilt the reconciliation logic on a governed, centralized data layer. Regional data sources were unified into a single Snowflake environment with role-based access aligned to each team’s scope. Reconciliation that had previously required manual aggregation across disconnected systems was replaced with automated pipelines running on clean, centralized data. The Kanerika team applied the same Snowflake implementation approach used across its enterprise client base: architecture-first, governance built in from the start, and delivery timelines accelerated via FLIP, Kanerika’s migration automation platform.
The Results 60% reduction in manual reconciliation effort across regional teams Real-time operational visibility replacing month-end reporting cycles A governed Snowflake data layer now serving as the foundation for further analytics and SiS app development built on top of the migrated estate
Wrapping Up Streamlit in Snowflake removes the infrastructure overhead that makes external data app hosting expensive. The warehouse runtime covers most internal enterprise use cases without additional setup. Cortex AI integration, write-back support, and native RBAC make SiS a strong choice for operational tools, AI-powered apps, and analyst-facing dashboards that need to stay close to governed data. The constraints (Snowflake account required for access, custom components unavailable, 16 MB per-query limit) are manageable with upfront architecture decisions. Getting the RBAC model and runtime choice right at the start determines how much rework appears in production.
Enterprise Data Needs More Than a Cloud Warehouse Kanerika helps you build the data foundation, governed, scalable, and AI-ready, that modern Snowflake deployments demand.
View Our Snowflake Practice →
Frequently Asked Questions What is Streamlit in Snowflake and how does it differ from standalone Streamlit? Streamlit in Snowflake, abbreviated as SiS, runs Streamlit apps as native objects inside Snowflake, using Snowflake’s compute, storage, and access control. Standalone Streamlit requires separate hosting, credential management, and its own authentication layer. SiS eliminates external infrastructure but requires a Snowflake account for app access, while standalone Streamlit can serve any authenticated user regardless of whether they have a Snowflake account.
What privileges are needed to create a Streamlit app in Snowflake? The creating role needs USAGE on the target database and schema, CREATE STREAMLIT and CREATE STAGE privileges on the schema, and USAGE on at least one warehouse. Running under ACCOUNTADMIN during initial setup is the simplest path to confirm the app works before isolating privilege configuration. For production, a dedicated role with only the required privileges is the recommended approach.
What is the difference between the warehouse runtime and the container runtime in SiS? The warehouse runtime runs apps using Snowflake’s Anaconda package channel, supports Python 3.9–3.11, and is simpler to configure. The container runtime supports any pip-installable library, allows public URL assignment, and requires a compute pool. Most internal enterprise apps are well served by the warehouse runtime. Container runtime is the right choice when the app needs packages outside Snowflake’s Anaconda channel or requires cross-session shared state.
How does Streamlit in Snowflake handle data security and access control? SiS inherits Snowflake’s RBAC model. Access to an app is granted using standard GRANT syntax, and the app runs under the owner role’s privileges by default. Data never leaves Snowflake to reach the app, which means existing network policies, encryption, and data masking rules apply automatically. Revoking a role removes access to both the app and the underlying tables that role was granted on.
Can Streamlit in Snowflake connect to Snowflake Cortex AI for LLM-powered apps? Yes. SiS apps call Cortex LLM functions via SQL using SNOWFLAKE.CORTEX.COMPLETE() or through the Snowpark Python API with snowflake.cortex.Complete(). LLM inference runs inside Snowflake’s infrastructure, so sensitive data is not transmitted to external API endpoints. Cortex supports models from Anthropic, OpenAI, Meta, and Mistral, and the model can be swapped by changing a single parameter.
What is the 16 MB limit in Streamlit in Snowflake and how do teams work around it? SiS caps the data returned from a single query at 16 MB. Apps that pull large result sets before filtering in Python hit this limit in production with full data volumes. The standard workaround is pushing filters into the SQL query or using Snowpark DataFrame operations server-side so Snowflake returns only the rows and columns the app actually needs, rather than the full dataset.
How is Streamlit in Snowflake deployed to production using CI/CD? Snowflake CLI 3.14.0 and later provides the snow streamlit deploy command, which uploads local app files to a stage and creates or replaces the Streamlit object in the target schema. GitHub Actions integration is the most common CI/CD pattern: a workflow triggers on push to the main branch, installs the CLI, writes connection credentials from repository secrets, and runs the deploy command. Separate connection configs for staging and production keep environments isolated.
How does Kanerika help enterprises implement Streamlit in Snowflake? Kanerika is a Snowflake Select Tier Partner that delivers end-to-end Snowflake implementations, including SiS app deployment, Cortex AI integration, RBAC design, and performance tuning. The team’s work starts with data architecture and governance, because SiS apps built on poorly structured data produce unreliable outputs regardless of how the application layer is built. Kanerika’s Snowflake practice spans data engineering, AI implementation, and platform governance across enterprise clients in manufacturing, financial services, and logistics.
