Streamlit Data Apps — Uncached Queries Exhaust DB Pool
Uncached queries per slider interaction cause 150+ DB connections and 503 errors.
20+ years shipping production Python across data and backend systems. Everything here is grounded in real deployments.
- ✓Solid grasp of fundamentals
- ✓Comfortable reading code examples
- ✓Basic production concepts
- Streamlit re-runs your entire Python script on every widget interaction — no callbacks, no event loop
- @st.cache_data caches serializable returns (DataFrames, API responses) — @st.cache_resource caches non-serializable objects (DB connections, ML models)
- st.session_state persists data across re-runs within a single browser session — but is lost on page refresh
- Use st.form() to batch widget inputs and prevent re-runs on every keystroke during data entry
- The #1 production mistake: loading data outside a cache decorator — every slider move re-queries the database
- Biggest misconception: Streamlit is only for prototypes. With proper caching and Docker deployment, it handles internal tools at enterprise scale
Imagine you've baked an amazing cake — your data analysis — but it's sitting in your kitchen where nobody can see it. Streamlit is like a pop-up bakery window. It takes your Python code and instantly gives it a front door, a menu, and a way for customers to interact with what you made. You don't need to know how to build a shop; you just focus on the cake. That's Streamlit: a way to share your data work with the world without learning web development.
Most data insights die in Jupyter notebooks. A data scientist builds a forecasting model, but only someone who can run Python can actually see it. Streamlit fixes this — it turns any Python script into a live web app with zero frontend code.
The core trade-off: Streamlit re-runs your entire script on every interaction. This makes the programming model dead simple — your code stays linear, no callback wiring. But it also means un-cached operations like database queries, model loading, and file reads fire on every slider move. Without disciplined caching, your app grinds to a halt after the second click.
Productionizing Streamlit requires three things: caching decorators on every expensive operation, st.session_state for cross-interaction state, and a deployment strategy — Docker, Streamlit Community Cloud, or Kubernetes. Miss any of these and you have a prototype that breaks under real usage.
Why Streamlit Data Apps Exhaust DB Pools
Streamlit is a Python framework that turns data scripts into interactive web apps. Its core mechanic: every user interaction or widget change triggers a full top-to-bottom re-execution of the script. This means each rerun opens new database connections unless you explicitly cache queries. Without caching, every slider drag or button click fires fresh SQL queries, each consuming a connection from the pool. In practice, a single user rapidly clicking through filters can consume 10–20 connections per minute. With 50 concurrent users, that's 500–1000 connections per minute — enough to exhaust a typical 100-connection pool in seconds. The result: connection timeouts, app hangs, and cascading failures across services sharing the same database. Use @st.cache_data to cache query results. Set TTLs that match your data freshness needs — seconds for real-time dashboards, minutes for daily reports. Never let a UI event become a direct database query.
psycopg2.OperationalError: FATAL: remaining connection slots are reserved for non-replication superuser connections.@st.cache_data(ttl=60) on any query that doesn't need real-time freshness — even for small datasets.@st.cache_data and a TTL; uncached queries are the #1 cause of pool exhaustion.How Streamlit's Execution Model Actually Works (This Changes Everything)
Before you write a single widget, you need to understand Streamlit's most important — and most surprising — design decision: every time a user interacts with your app, Streamlit re-runs your entire Python script from top to bottom. Every. Single. Time.
This is completely different from how most web frameworks operate. There is no event loop, no callbacks, no onclick handler wiring. When a user moves a slider, Streamlit re-executes your script with the new slider value baked in as the widget's return value. It sounds expensive, and it can be — but it is also what makes Streamlit so easy to reason about.
The upside: your app logic stays linear and readable, exactly like a regular Python script. The downside: if you are loading a 2GB CSV or running a complex SQL query on every re-run, your app will be unusably slow within seconds. That is why caching is not optional — it is the single most critical design decision in any Streamlit app.
- No callbacks, no event loop — your code runs top-to-bottom on every interaction
- Widget return values change between re-runs, but the code structure stays identical
- This makes the mental model dead simple: write a script, add widgets, done
- The cost: every uncached operation re-executes — this is why caching is mandatory, not optional
- Think of it as replaying your script with new inputs each time, not patching specific components
Caching and State: Making Your App Fast and Stateful
Streamlit gives you two caching decorators and they solve different problems. @st.cache_data is for functions that return data — CSVs, API responses, processed DataFrames. It serializes the return value using pickle, which means every user session gets its own copy. @st.cache_resource is for non-serializable objects like database connections or ML models — it stores the object reference directly and shares it across all sessions.
Then there is st.session_state — a dictionary that persists for the lifetime of a user's session. It disappears on page refresh, but it survives every re-run within that session. It is how you build multi-step forms, track login status, or accumulate user inputs without losing them between interactions.
st.cache_data.clear() from a refresh button for manual invalidationBuilding a Real Multi-Page Data App with Layout and Forms
Real data apps require navigation, structured layouts, and forms that do not re-run the entire script on every character the user types. Streamlit handles multi-page navigation through a pages/ directory — any Python file placed there is automatically discovered and shown in the sidebar. Layout primitives like st.columns() and st.tabs() handle visual organization within a page.
Forms are particularly important for production apps. Without st.form(), every keystroke in a text input triggers a full script re-run — which means every keystroke fires your cached data loading function's cache key check, re-renders the entire chart, and redraws the page. With st.form(), all widget changes inside the form are buffered locally and a single re-run fires only when the user explicitly clicks the submit button.
st.set_page_config(), you will get a StreamlitAPIException that halts the entire app. This includes st.write(), st.title(), and even importing a module that calls a Streamlit function at import time. Make st.set_page_config() the absolute first line after your imports.st.form() to prevent cascading re-runs during data entry.st.set_page_config() as the absolute first Streamlit command — any call before it raises an exception that crashes the app on startup.st.columns() for side-by-side layout — no multi-page complexity neededst.form() — it prevents re-runs on every keystroke and fires once cleanly on submitst.form() — use individual widgets outside a form so each keystroke triggers the updateData Persistence: The SQL Backend
Streamlit's st.session_state is ephemeral by design. It lives in server memory, scoped to a single browser session, and disappears the moment the user refreshes the page, closes the tab, or the server restarts. For anything that needs to survive beyond a single session — audit logs, saved analysis results, user preferences, cross-session dashboards — you must write to an external persistent store.
At the enterprise level, a structured SQL backend is the standard approach. The pattern is straightforward: use @st.cache_resource to create a shared database connection pool once, and write session events to an audit table on key user actions. This gives you a complete record of dashboard activity without impacting the read performance of your main queries.
Java Integration: Consuming Dashboards via API
In hybrid infrastructure environments, your Streamlit app often serves as the UI layer for a Java or Go-based compute engine. The pattern is clean: the Java service owns the business logic and heavy computation, exposes it via a REST endpoint, and Streamlit calls that endpoint, caches the response, and handles visualization. This separation of concerns keeps your Streamlit script lightweight and your backend independently testable and deployable.
The critical rule: always cache the API call with @st.cache_data. Without it, Streamlit calls your Java backend on every single re-run — which means every slider move, every checkbox toggle, every character typed fires an HTTP request to your backend service. Under even modest concurrency, this becomes a self-inflicted DDoS.
st.empty() with a polling loop as a stopgap, or switch to Dash or Panel for a proper streaming UIDeploying Your Streamlit App — From Local to Live
For production deployments, Docker is the standard. It guarantees that your runtime environment — including system-level dependencies for libraries like OpenCV, PyTorch, or GeoPandas — is identical from local development to production. It also makes secrets management, health checking, and container orchestration straightforward.
The single most common Docker deployment mistake with Streamlit: forgetting --server.address=0.0.0.0. Without it, Streamlit binds to 127.0.0.1 inside the container. The app starts, the process runs, but no external connection can reach it. You see 'connection refused' in the browser and nothing obviously wrong in the logs.
Your First Streamlit App: The 'Hello, World' That Will Break Production
Installing Streamlit is the easy part. Understanding why your first app might crash DB pools is the lesson. Run pip install streamlit and verify with streamlit --version. That command pulls in Tornado, the async server that hijacks your script execution. Now create a file: every time your script runs—on each button click, each slider move—Tornado executes the entire file from top to bottom. That means every database connection, every API call, every expensive compute runs fresh. Do not, under any circumstances, put a production database query inside an unconditional . You will exhaust your connection pool in minutes. Instead, start simple: st.write()import streamlit as st; st.title("DB Killer"). Run it with streamlit run app.py. See that URL http://localhost:8501? That's your new home. Remember: Streamlit is not Flask. Every rerun is a full execution. Design for that.
@st.cache_data with a TTL or manage connections manually with st.connection().Widgets: The Silent Rerun Trigger Nobody Warned You About
Streamlit widgets look harmless. A slider, a button, a text input. Click one, and the whole script reruns. That's the design. But it's also the reason your dashboard feels sluggish and your API endpoints get hammered. Understand the lifecycle: when a widget changes value, it triggers a re-execution. Streamlit collects the new value, runs your script top-to-bottom, and redraws only the parts that changed. But if you have a followed by a st.slider() that recomputes 10GB of data, you've built a performance trap. The fix: use st.plotly_chart()session_state to cache widget values and prevent unnecessary recomputation. Check st.session_state for existing values before running heavy operations. Also, never put API calls inside event handlers—they fire on each rerun, not just the click. For buttons, wrap the action in a conditional: if st.button("Run"): ensures the block executes only when clicked. Your fellow engineers will thank you.
key arguments on widgets to track them in session_state. Combine with on_change callbacks to control when heavy operations fire. This pattern saved us from a 5-second UI freeze on every slider drag.Streamlit 1.x in 2026: New Features
As of 2026, Streamlit 1.x has introduced several powerful features that enhance app performance and developer experience. Key additions include native support for st.cache_resource for managing global resources like database connections, improved session state with st.session_state for persistent data across reruns, and the new st.fragment decorator for granular caching of UI components. Additionally, Streamlit now offers built-in theming via st.set_page_config and experimental support for async functions with st.runtime. These features allow developers to build more efficient and scalable data apps. For example, using st.cache_resource to manage a database connection pool prevents resource exhaustion:
```python import streamlit as st from sqlalchemy import create_engine
@st.cache_resource def get_engine(): return create_engine("postgresql://user:pass@localhost/db")
engine = get_engine() ```
This ensures only one connection pool is created, avoiding the common pitfall of exhausting database connections on each rerun.
st.cache_resource for database connections and external API clients to prevent resource leaks and improve scalability.st.cache_resource, improved session state, and st.fragment for efficient caching and state management, reducing common performance issues.Streamlit vs Gradio vs Dash: App Framework Comparison
Choosing the right framework for building data apps depends on your use case. Streamlit excels in rapid prototyping and simplicity, with a linear script execution model that automatically reruns on user interaction. Gradio is ideal for machine learning demos, offering easy integration with models and built-in sharing via Hugging Face Spaces. Dash, built on Plotly.js, provides maximum customization for complex, production-grade dashboards but requires more boilerplate. Here's a quick comparison:
- Streamlit: Best for quick data exploration and internal tools. Example: a simple data viewer.
- Gradio: Best for ML model demos and interactive notebooks. Example: image classification interface.
- Dash: Best for enterprise dashboards with complex layouts and callbacks. Example: multi-page analytics dashboard.
Performance-wise, Streamlit's rerun model can be inefficient for large datasets, while Dash's callback system is more efficient but complex. Gradio's event-driven model is lightweight for single-model apps. For a simple data filtering app:
``python # Streamlit import streamlit as st df = pd.read_csv('data.csv') filter = st.selectbox('Filter', df['column'].unique()) st.write(df[df['column'] == filter]) ``
In Dash, this requires defining callbacks and layout components, making it more verbose but offering finer control.
Streamlit Performance: Caching, Session State, and Deployment
Optimizing Streamlit performance is crucial for production apps. The three pillars are caching, session state, and deployment configuration. Caching with @st.cache_data and @st.cache_resource prevents redundant computations and database queries. Session state (st.session_state) preserves data across reruns, avoiding reinitialization. For deployment, use a production server like Gunicorn with multiple workers, but ensure each worker has its own cache to avoid conflicts. Example of caching a heavy computation:
import streamlit as st
import pandas as pd
@st.cache_data
def load_data():
return pd.read_csv('large_dataset.csv')
df = load_data()
st.write(df.head())
Session state can store user-specific data:
if 'user' not in st.session_state:
st.session_state.user = 'guest'
st.write(f"Hello, {st.session_state.user}")
For deployment, set server.maxUploadSize and use server.enableCORS appropriately. Also, consider using st.cache_resource for database connections to avoid connection pool exhaustion. A common pitfall is not clearing cache when data changes; use or set st.cache_data.clear()ttl parameter.
@st.cache_data and @st.cache_resource, combined with session state and proper deployment settings, dramatically improves Streamlit app performance.Internal dashboard hammered the production database — uncached query fired on every widget interaction
st.form() around all input widgets so re-runs only happen on explicit submit, not on every keystroke or slider nudge. 4. Moved the dashboard connection to a read replica instead of hammering the primary. 5. Added a Streamlit-specific connection pooler using st.connection with SQLAlchemy, capped at 5 connections.- Streamlit re-runs the entire script on every interaction — uncached database queries will destroy your database under any real concurrency.
- @st.cache_data is not optional for production apps — it is the single most important performance decision you will make.
- Always point analytics dashboards at a read replica — never query the production primary from a UI layer.
- st.form() prevents re-runs during data entry — use it for any multi-input workflow where users adjust several controls before committing.
- Test with realistic concurrency before you deploy — 10 simultaneous users behave nothing like a single developer clicking through one scenario.
st.cache_data.clear() programmatically. For user-controlled refresh, add a clearly labeled 'Refresh Data' button that calls the clear function and immediately triggers a re-run.st.error() to surface failures gracefully rather than crashing the session.python -m cProfile -s cumtime -m streamlit run app.py 2>&1 | head -30pip install streamlit-profiler && streamlit-profiler run app.py| File | Command / Code | Purpose |
|---|---|---|
| execution_model_demo.py | st.write(f"Script last ran at: {datetime.datetime.now().strftime('%H:%M:%S')}") | How Streamlit's Execution Model Actually Works (This Changes |
| caching_and_state_demo.py | @st.cache_data(ttl=3600) # Cache expires after 1 hour — reduces DB load signifi... | Caching and State |
| professional_dashboard.py | st.set_page_config( | Building a Real Multi-Page Data App with Layout and Forms |
| io | CREATE TABLE IF NOT EXISTS io.thecodeforge.dashboard_activity ( | Data Persistence |
| io | /** | Java Integration |
| Dockerfile | FROM python:3.11-slim | Deploying Your Streamlit App |
| app.py | conn = psycopg2.connect("dbname=prod") | Your First Streamlit App |
| widget_trap.py | x = st.slider("X", 0, 100) | Widgets |
| streamlit_new_features.py | from sqlalchemy import create_engine | Streamlit 1.x in 2026 |
| comparison_example.py | df = pd.read_csv('data.csv') | Streamlit vs Gradio vs Dash |
| performance_optimization.py | @st.cache_data(ttl=3600) # Cache for 1 hour | Streamlit Performance |
Key takeaways
st.form() to batch widget interactions into a single re-run on submitInterview Questions on This Topic
Describe three concrete strategies for optimizing a slow Streamlit app that has 50 concurrent users and re-runs taking 8+ seconds.
st.form() around multi-widget inputs — Streamlit Community Cloud, Streamlit Cloud connections, and ML models loaded via @st.cache_resource. This is non-negotiable. Third: use st.form() for multi-input workflows so a re-run fires once on submit instead of once per keystroke. Additionally, minimize work in the script body — move expensive setup into cached functions, keep the top-level script as lightweight as possible. Use st.empty() and st.container() for partial UI updates where appropriate, and point the dashboard at a read replica rather than the production primary database.Frequently Asked Questions
20+ years shipping production Python across data and backend systems. Everything here is grounded in real deployments.
That's Python Libraries. Mark it forged?
6 min read · try the examples if you haven't