Streamlit st.session_state limits: server-side memory and per-tab session scope
0 reputation · 07 Feb 2020, 07:02 UTC
0 reputation · 07 Feb 2020, 07:02 UTC
Streamlit's st.session_state is documented to persist values across script reruns within a single user session, behaving like a Python dictionary that can hold complex objects such as DataFrames. State is scoped to one browser tab and stored on the server side, so every object placed there occupies memory in the server process for the lifetime of that session.
A design question arises when an app needs to keep a moderately sized DataFrame plus derived values available across reruns. The documented behavior covers persistence and isolation, but it does not state a size ceiling, and large session objects raise the server's memory footprint while multiple tabs multiply that usage. State is also not shared between users, which pushes any global data toward external storage.
Specific questions:
st.session_state before server memory becomes a risk?st.cache_data or an external database?34775 reputation · 07 Feb 2020, 14:13 UTC
There is no documented hard size limit for st.session_state. The practical ceiling is the RAM available to the Streamlit server process. Objects remain in memory, uncompressed, for the lifetime of the session, so a DataFrame costs approximately its in-memory Python size.
Per-tab isolation means each browser tab receives its own session and its own copy of st.session_state. One user with five tabs holding the same 100 MB DataFrame can consume roughly 500 MB for that object alone, plus interpreter overhead. Aggregate memory scales approximately linearly with concurrent tabs.
Keep user-specific, transient data in st.session_state: widget values, form inputs, current step, short-lived intermediate results. Use st.cache_data for expensive, shareable, read-only computations reused across sessions. Move large, long-lived, or multi-user datasets to an external database or object store.
| Item | Status | Detail |
|---|---|---|
Hard st.session_state size limit | Not documented | Bounded by server process RAM; no automatic compression or paging. |
| Per-tab memory scaling | Expected behavior | Independent sessions; memory roughly proportional to tab count for identical objects. |
| Session state lifetime | Documented | Persists across reruns; released when the session ends. |
st.cache_data sharing | Documented | Can share computed results across sessions, but still consumes RAM until evicted. |
st.session_state.df.psutil or docker stats.st.cache_data and compare process RAM; cached data may be shared but is not automatically evicted on session end.import os
import psutil
process = psutil.Process(os.getpid())
print(f"{process.memory_info().rss / 1e6:.1f} MB")
Confirm the expected peak number of concurrent sessions or tabs on the server. That figure, multiplied by the per-session object size, determines whether session state fits in available RAM or whether external storage is required.
This draft assumes Streamlit 1.x server-side execution. Memory figures are illustrative and require verification against your app, data size, and server environment. Because current verification has not been completed, treat specific size thresholds as provisional.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.