n8n + Streamlit Pipeline Dashboard

Same architecture, different direction of flow. Here data moves one way on a schedule: n8n fetches and transforms, PostgreSQL stores, Streamlit displays, and no user input ever enters the workflow. The AI Agent stack inverts that: a user action in Streamlit triggers an n8n workflow through a webhook and an LLM processes the input before the result returns to the screen. That difference sets the failure modes and the bill: this stack worries about ingestion schedules and refresh cadence with essentially zero marginal cost, while the AI stack worries about webhook latency and per-token spend. If the dashboard answers known questions from collected data, use this one; if it responds to what users type, use the other.

Effectively the price of one small server. Every component is free open source: n8n self-hosted, Streamlit, Pandas, Python, and PostgreSQL carry no license cost, so a $5 to $10 a month VPS runs the whole pipeline for a small team, with no per-seat or per-row charges anywhere. The managed alternatives: n8n's cloud plans start at $20 a month billed yearly (2,500 executions) and Streamlit's Community Cloud hosts the dashboard free, which removes the server entirely for light use. That flat cost is the stack's main advantage over SaaS dashboard and ETL tools, which bill per connector, per row, or per seat as volume grows.

If the dashboard's questions are known and the transformations are simple, a BI tool genuinely is the faster choice: connect Metabase to the same PostgreSQL and non-developers build charts without Python. This stack earns its extra moving parts when the pipeline or the visualization needs logic BI tools cannot express: an n8n workflow that cleans, enriches, and cross-references API data before it ever reaches the database, or a Streamlit page that runs a Pandas transformation, a statistical calculation, or a custom chart a BI query builder cannot produce. A practical hybrid: keep n8n for ingestion regardless, and choose Streamlit only when the display layer outgrows drag-and-drop charts.

Freshness has two dials, and they are independent. Ingestion cadence is set in n8n: each source workflow runs on its own schedule (every five minutes, hourly, nightly), which bounds how current the PostgreSQL tables can ever be. Read freshness is effectively real time: every Streamlit rerun queries PostgreSQL directly, so the dashboard always reflects whatever the last ingestion wrote. Between the two sits caching: Streamlit's cache_data decorator with a time-to-live keeps heavy queries from re-running on every widget interaction. For sources that push instead of polling, an n8n webhook trigger makes ingestion event-driven and the schedule dial disappears. Sub-second end-to-end freshness is not this stack's shape; seconds-to-minutes is.

Yes, and the pieces graduate separately. The typical path: PostgreSQL fills up, and either it moves to a managed instance or the history outgrows it and graduates to a warehouse, at which point the catalog's ELT stacks (Airbyte, dbt, and a warehouse like Snowflake) take over the heavy transformation work. n8n remains viable much longer than teams expect: scheduled ingestion of API sources keeps working well into the tens of thousands of rows a day, and its replacement, when needed, is a orchestrator like Airflow rather than a rewrite of the sources. Streamlit never needs replacing for an internal audience. The realistic inflection point is when transformations need dbt-style versioned SQL rather than visual n8n steps; that is the layer to move first.