Streamlit on Snowflake

Running natively inside Snowflake means the app queries data with no network hop, no separate credentials to manage, and Snowflake's own access controls apply automatically, worth it specifically when the data can't leave Snowflake's governed environment.

Not necessarily more, just billed differently: instead of a separate hosting bill, the app's compute is billed the same way any other Snowflake query is, as part of existing warehouse usage.

Because an open app keeps its session, and with it the app's warehouse, active until the session times out from inactivity. A dashboard left open in a browser tab bills like a long query. Run apps on a dedicated X-Small warehouse rather than a shared larger one, and give heavier queries their own warehouse if needed. Cache query results in the app with Streamlit's data caching, so reruns triggered by each widget click reuse results instead of querying Snowflake again, and check the app's warehouse in Snowflake's usage views after the first week.

Not by default. Packages come from the channel Snowflake provides for its Python runtime, which covers the common data libraries but not everything on PyPI, so check a package is available before designing around it. Outbound network calls are blocked unless an administrator sets up an external access integration for the specific domains the app needs, which matters for apps that call an LLM API or a third-party service. Plan both before building; they are the usual reasons a Streamlit app that runs locally fails inside Snowflake.

No, and this surprises many teams. A Streamlit app in Snowflake runs with the rights of its owner's role, so every viewer sees whatever that role can query, regardless of their own permissions. Give each app a dedicated owner role granted only the tables it needs. When different viewers must see different rows, filter inside the app using the signed-in viewer's identity, which Streamlit exposes to the app, or split the audiences into separate apps with separate owner roles.