Limitations and library changes¶

Unsupported Streamlit features¶

The following Streamlit features are not fully supported in Streamlit in Snowflake:

• st.set_page_config:

  The page_title, page_icon, and menu_items properties of the st.set_page_config command aren’t supported.

• config.toml file:

  For a summary of supported and unsupported configuration options, see Streamlit configuration.

Loading external resources¶

All Streamlit in Snowflake apps run within a Content Security Policy (CSP) that restricts what resources can be loaded. The CSP blocks loading code from external domains and embedding external content in iframes. It also blocks front-end calls that are generally considered unsafe, like eval(). For more information about the CSP, see Content Security Policy.

For example, the following code runs without a Python error, but the script is not loaded or executed in the browser:

# This won't work
st.html(
   "<script src="http://www.example.com/example.js"></script>",
   unsafe_allow_javascript=True
)

Custom components¶

As a consequence of the CSP, custom components can’t load scripts from external domains in warehouse and container runtimes. Because package-based components use an asset directory to serve their static content, the following differences apply:

• In warehouse runtimes, package-based v2 components that utilize an asset directory aren’t supported.

• In container runtimes, package-based v2 components are fully supported.

To use a v2 custom component in a warehouse runtime, it must be defined with inline HTML, CSS, and JavaScript.

Query parameters¶

For st.query_params in Streamlit in Snowflake, a streamlit- prefix is added to each query parameter key in the URL. This prefix isn’t included when you use st.query_params to get or set a value.

For example, consider the following URL:

https://app.snowflake.com/org/account_name/#/streamlit-apps/DB.SCHEMA.APP_NAME?streamlit-first_key=one&streamlit-second_key=two

The parameters in this URL are accessible in st.query_params as the following key-value pairs:

{
   "first_key" : "one",
   "second_key" : "two"
}

Displaying large amounts of data¶

Streamlit apps running in warehouse runtimes have a 32-MB limit on the size of messages exchanged between the backend and the frontend. If you attempt to display more than 32 MB of data with a single Streamlit command, like st.dataframe, the following error occurs:

MessageSizeError: Data Size exceeds message limit

To avoid this limit, design your Streamlit app to display data in increments smaller than 32 MB. There is no explicit limit on the size of a query you can run or the amount of data you can have in memory.

In container runtimes, this limit defaults to 200 MB and can be changed by setting the Streamlit configuration option, server.maxMessageSize. However, the message size can’t exceed the capacity of the container’s memory. Allowing larger messages could exceed the container’s memory limit, especially if concurrent viewers are present.

File uploads¶

The default file-size limit for st.file_uploader and st.chat_input is 200 MB. In warehouse runtimes, this isn’t configurable. In container runtimes, this limit can be changed by setting the Streamlit configuration option, server.maxUploadSize. However, the file size can’t exceed the capacity of the container’s memory. Allowing larger files could exceed the container’s memory limit, especially if concurrent viewers are present.

For larger files, consider processing data in smaller batches or using alternative uploading methods.

Mapbox and Carto¶

Mapbox and Carto provide map tiles when you use the st.map or st.pydeck_chart Streamlit commands.

In warehouse runtimes, which manage their packages with conda, Mapbox and Carto are third-party applications that are subject to Snowflake’s External Offerings Terms.

To use these commands in warehouse runtimes, you must acknowledge the External Offerings Terms. Container runtimes don’t require this acknowledgement.

Caching¶

Caching is partially supported in warehouse runtimes and fully supported in container runtimes.

In warehouse runtimes, caching is limited to single-session caching. Cached values can’t be shared between sessions. In container runtimes, caching is fully supported. Cached values are shared across all viewer sessions.