Operator Module · Tier 1
Streamlit in Snowflake
Quick Start for Internal Data Tools
Ship production-grade internal data apps that run inside Snowflake — no external hosting, no separate authentication, no copy of the data leaving the platform. Streamlit in Snowflake is the fastest path from Python notebook to shared internal tool your team actually uses.
Learning objectives
01
Understand what Streamlit in Snowflake is and when it beats traditional BI dashboards.
02
Deploy your first Streamlit app using the Snowflake CLI.
03
Apply the five-step deployment pattern from local development to production sharing.
04
Diagnose the six common failure patterns specific to Streamlit-in-Snowflake.
05
Configure RBAC sharing patterns that work for cross-team apps.
06
Manage Streamlit warehouse costs and performance for scaled adoption.
Duration
60 minutes
plus lab
Prerequisites
Python basics
Snowflake CLI
Why this matters
Most internal data tools are either over-engineered (built on full web frameworks with separate infra) or under-engineered (Excel files emailed around). Streamlit in Snowflake is the middle path — Python-fast development, production-grade governance, zero separate hosting. Teams that adopt it ship 5x more internal tools with 80% less infrastructure work.
00
Module Contents
What this module covers
This module is the practitioner's guide to Streamlit in Snowflake — from first deployment to production sharing patterns. By the end you will have an app deployed and shared with your team, plus the governance and cost discipline to scale Streamlit adoption without surprises.
01
What Streamlit in Snowflake is
The architecture, when it beats traditional BI, when traditional BI wins.
p.03
02
Anatomy of a Streamlit app
File structure, Snowflake session model, native data access patterns.
p.04
03
The five-step deployment pattern
Local dev, push, role share, validate, monitor.
p.05
04
Diagnosing Streamlit failures
Six common patterns — package availability, role context, secret handling.
p.06
05
RBAC sharing patterns
Cross-team sharing, role context for data access, governance boundaries.
p.07
06
Cost and performance management
Warehouse choice, caching, query optimization for Streamlit workloads.
p.08
07
Hands-on lab worksheet
Deploy your first Streamlit app and share it across teams.
p.09
08
Knowledge check
Five questions covering architecture, deployment, RBAC, and cost.
p.10
09
Glossary and reference
Terminology, deployment commands, and a production readiness checklist.
p.11
10
Module completion and next steps
Module summary, certificate, next in series.
p.12
01
Chapter 01
What Streamlit in Snowflake is
Streamlit in Snowflake (SiS) is Snowflake's native hosting of the Streamlit Python framework. You write standard Streamlit code; Snowflake runs it inside your account using a designated warehouse. The app has direct, authenticated access to your Snowflake data without separate credentials, network paths, or data extraction. No data leaves the platform.
Three architectural advantages
Advantage 01 — No separate hosting. Traditional Streamlit deployment requires a server, container, or PaaS (Heroku, Streamlit Cloud, internal Kubernetes). Streamlit in Snowflake runs inside your existing Snowflake account. Zero infrastructure setup.
Advantage 02 — Native authentication. Apps inherit the viewer's Snowflake identity and role. RBAC just works — users see only data their role can see. No JWT plumbing, no separate user databases, no permission-checking middleware.
Advantage 03 — Data locality. Queries execute against Snowflake natively. No data extraction, no cached copies, no governance gaps. The app is just code running close to the data.
When traditional BI still wins
Streamlit wins
Bespoke internal tools, custom workflows, interactive parameter exploration, ML model interfaces, data quality dashboards with one-off logic, anything where Python flexibility beats drag-and-drop.
Traditional BI wins
Pixel-perfect executive dashboards, scheduled report delivery, complex pivot-table-style analytics, anything where business users author content themselves. Streamlit requires Python authors.
The right mental model
Streamlit in Snowflake replaces Jupyter-notebooks-shared-via-Slack, not Tableau dashboards. It's a tool for data engineers and analysts to ship internal apps faster — not a replacement for the BI platform serving the executive team.
02
Chapter 02
Anatomy of a Streamlit app
A Streamlit-in-Snowflake app has three components: the Python file (your app code), the environment definition (Python packages), and the Snowflake stage that stores both. Snowflake handles serving, authentication, and execution.
Minimum viable structure
# File: streamlit_app.py
import streamlit as st
from snowflake.snowpark.context import get_active_session
session = get_active_session() # Native auth — no credentials needed
st.title("Order Volume Dashboard")
# Query Snowflake directly
df = session.sql("""
SELECT order_date, SUM(order_total) AS revenue
FROM SALES.ORDERS
WHERE order_date >= DATEADD('day', -30, CURRENT_DATE())
GROUP BY order_date
ORDER BY order_date
""").to_pandas()
st.line_chart(df, x='ORDER_DATE', y='REVENUE')
Environment file
# File: environment.yml
name: streamlit_env
channels:
- snowflake
dependencies:
- python=3.11
- streamlit
- snowflake-snowpark-python
- pandas
- plotly
The session model
get_active_session() is the magic. It returns a Snowpark session authenticated as the user viewing the app, with their default role. Your code never handles credentials. Snowflake handles identity propagation transparently. RBAC works without your intervention.
Operator Tip
Only use Snowflake-channel packages. The conda-forge or PyPI channels are not available in Streamlit-in-Snowflake. If a package you need isn't in the Snowflake channel, you'll need a different deployment model. Check availability before promising delivery.
03
Chapter 03
The five-step deployment pattern
Step 01 — Local dev
Build and test locally before deploying
Develop the app on your laptop using streamlit run streamlit_app.py. Use a connection to a development Snowflake account. Iterate quickly without paying Snowflake compute for every change.
Step 02 — Push
Deploy via Snowflake CLI
Once local testing passes, push to Snowflake with a single command. The CLI handles file upload, stage creation, and app registration.
snow streamlit init my_dashboard
snow streamlit deploy --connection prod
Step 03 — Role share
Grant USAGE on the Streamlit object
Share the app with the roles that need access. Users with that role can open the app from Snowsight. They inherit their own role's data access — same app, different visible data per viewer.
GRANT USAGE ON STREAMLIT my_dashboard TO ROLE ANALYST_ROLE;
Step 04 — Validate
Test with the actual target role
Switch into the target role yourself or have a member of that team open the app. Confirm data visibility matches expectations. Most "bug" reports turn out to be RBAC visibility issues; catch them in validation.
Step 05 — Monitor
Track usage and warehouse cost
Streamlit apps consume warehouse credits while open. Monitor warehouse usage by app. Identify apps that get heavy use and apps that have been abandoned. Adjust warehouse sizing accordingly.
Operator Tip
Always do local development before deploying. Each redeploy to Snowflake takes 30 seconds and consumes credits. Local development with streamlit run is instant and free. Catch typos and logic bugs locally; use Snowflake only for the final deployed app.
04
Chapter 04
Diagnosing Streamlit failures
| Symptom | Root cause and fix |
|---|
| "ModuleNotFoundError" on a package that works locally | Package not in Snowflake channel. Check Snowflake's allowed packages list. If not available, restructure to avoid the dependency or use a different deployment model. |
| App shows different data for different users | Working as designed — RBAC. The user is seeing what their role can see. This is a feature, not a bug. Document expected behavior. |
| App is slow despite light query load | Warehouse is undersized or auto-suspended. Streamlit apps need a running warehouse. Use a small but dedicated warehouse with longer auto-suspend (5 min) for Streamlit. |
| Deployment succeeds but app shows blank page | Python syntax error not caught locally. Check the app logs via snow streamlit get-url and view the browser console. |
| "Insufficient privileges" error on data access | App user has USAGE on Streamlit but not SELECT on referenced tables. Grant data access to the same role that has Streamlit access. |
| Secrets need to be used (API keys, etc) | Use Snowflake's SECRET object plus EXTERNAL ACCESS INTEGRATION. Never hardcode secrets in app code. |
The RBAC discipline
Most "Streamlit doesn't work" tickets are actually RBAC problems. The user has USAGE on Streamlit but not SELECT on the data. Always grant data access alongside Streamlit access. Bundle the grants into the role design.
05
Chapter 05
RBAC sharing patterns
Streamlit's authentication model inherits the viewer's role. Two patterns make this work cleanly at scale.
Pattern 01 — Bundled access role
Create a dedicated role for each app that combines Streamlit USAGE with the data SELECT grants needed. Grant the bundled role to users. Single grant, complete access.
# Bundled role pattern
CREATE ROLE APP_ORDER_DASHBOARD;
GRANT USAGE ON STREAMLIT my_dashboard TO ROLE APP_ORDER_DASHBOARD;
GRANT USAGE ON DATABASE ANALYTICS TO ROLE APP_ORDER_DASHBOARD;
GRANT USAGE ON SCHEMA ANALYTICS.SALES TO ROLE APP_ORDER_DASHBOARD;
GRANT SELECT ON ANALYTICS.SALES.ORDERS TO ROLE APP_ORDER_DASHBOARD;
GRANT USAGE ON WAREHOUSE APP_WH TO ROLE APP_ORDER_DASHBOARD;
# Single grant per user
GRANT ROLE APP_ORDER_DASHBOARD TO USER alice;
Pattern 02 — Role-aware app design
For apps used across multiple departments where each sees different data, design the app to use CURRENT_ROLE() in queries. The app shows different content per viewer without needing app-side authorization logic.
# Role-aware app pattern
SELECT * FROM ORDERS
WHERE region_code IN (
SELECT allowed_region
FROM ROLE_REGION_MAP
WHERE role_name = CURRENT_ROLE()
)
Operator Tip
Use Pattern 01 for most apps. It's simpler. Use Pattern 02 only when you have a clear cross-departmental access requirement and the regions/departments are stable. Don't add Pattern 02 complexity until you actually need it.
06
Chapter 06
Cost and performance management
Streamlit apps consume warehouse credits while users are interacting. A popular app open by 20 users simultaneously can produce significant credit consumption. Three disciplines keep cost manageable.
Discipline 01 — Dedicated Streamlit warehouse
Don't share a warehouse between Streamlit apps and ETL pipelines. Streamlit's workload pattern (many small queries, interactive) differs from ETL (few large queries, scheduled). A dedicated XS or S warehouse with auto-suspend at 5 minutes is the right starting point.
Discipline 02 — Aggressive caching
Use @st.cache_data on every function that queries Snowflake. Without caching, the app re-runs every query on every UI interaction — interaction count multiplied by query count multiplied by warehouse cost. Caching reduces this by 90% for typical apps.
# Cache pattern — every Snowflake query
@st.cache_data(ttl=300) # 5-minute cache
def get_orders(start_date, end_date):
return session.sql(f"""
SELECT * FROM ORDERS
WHERE order_date BETWEEN '{start_date}' AND '{end_date}'
""").to_pandas()
Discipline 03 — Adoption monitoring
Quarterly audit of all Streamlit apps. Apps with zero users in 60 days are candidates for removal.
Per-app warehouse cost tracking. Apps consuming >$500/month justify investigation.
Caching audit — every Snowflake query function should have @st.cache_data.
07
Chapter 07
Hands-on lab worksheet
Task 01
Set up local development environment
10 min
Install streamlit and snowflake-snowpark-python. Configure a Snowflake CLI connection to a dev account. Run a hello-world streamlit app locally.
Task 02
Build a single-page app with one Snowflake query
15 min
Write streamlit_app.py that queries a table you have access to and displays a chart. Test locally until it works.
Task 03
Deploy to Snowflake using snow streamlit deploy
10 min
Create environment.yml. Run snow streamlit init and snow streamlit deploy. Confirm the app appears in Snowsight.
Task 04
Create the bundled role and grant to a teammate
10 min
Build the APP_X_ROLE pattern from Chapter 05. Grant it to a colleague. Confirm they can open and use the app.
Task 05
Add caching and measure cost reduction
15 min
Add @st.cache_data to every Snowflake query function. Measure warehouse credit consumption before and after with QUERY_HISTORY.
08
Chapter 08
Knowledge check
Question 01
When does Streamlit in Snowflake beat traditional BI?
A
For pixel-perfect executive dashboards
B
For bespoke internal tools, ML interfaces, and custom workflows where Python flexibility matters
C
For business users to author content themselves
D
For scheduled report delivery
Question 02
get_active_session() returns:
A
A generic Snowflake admin session
B
A session authenticated as the viewing user with their default role
C
A read-only metadata session
D
An anonymous session
Question 03
A "ModuleNotFoundError" for a package that works locally most likely means:
A
The deployment is broken
B
The package is not available in the Snowflake conda channel
C
Python is the wrong version
D
The warehouse is too small
Question 04
An app shows different data to different users. This is:
Question 05
The single largest cost optimization for a Streamlit app is:
09
Chapter 09
Glossary and reference
Key terminology
Streamlit in Snowflake (SiS)
Snowflake's native hosting of the Streamlit framework. Apps run inside your account on a designated warehouse.
get_active_session()
Snowpark function that returns a session authenticated as the viewing user with their default role.
Bundled access role
A dedicated role combining Streamlit USAGE with all data grants needed for the app. Single grant per user.
@st.cache_data
Streamlit decorator that caches function output. Essential for cost management — apply to every Snowflake query function.
environment.yml
The conda-style environment definition. Lists Python version and packages. Only Snowflake-channel packages allowed.
SECRET object
Snowflake construct for storing API keys and credentials. Combined with EXTERNAL ACCESS INTEGRATION for safe external API calls from Streamlit.
Production readiness checklist
Local development works before any Snowflake deployment
environment.yml uses only Snowflake-channel packages
Every Snowflake query function has @st.cache_data with appropriate TTL
Bundled access role created with all required grants
Dedicated warehouse for Streamlit workloads (not shared with ETL)
Auto-suspend set to 5 minutes on Streamlit warehouse
App tested with the actual target user role
Quarterly review cadence for app usage and cost
10
Chapter 10
Module completion
What you learned
The architecture
Native hosting, native auth, native data access. Why Streamlit in Snowflake beats traditional Streamlit deployment for internal tools.
Deployment pattern
Local dev, push, role share, validate, monitor. The five-step workflow from idea to shared production app.
RBAC sharing
Bundled access roles and role-aware app design. Two patterns that scale across teams.
Cost management
Dedicated warehouses, aggressive caching, adoption monitoring. The discipline that keeps Streamlit affordable at scale.
Cloud On Demand · Operator Module Completion
Streamlit in Snowflake
Quick Start
Awarded to the practitioner who completed module OPR-002
Recipient signature
Issued by Cloud On Demand · OPR-002 · v1.0
Next in series
OPR-003 · ACCOUNT_USAGE FinOps Queries
→