Building a Live n8n Dashboard With Supabase and React

Every operations team eventually asks for the same thing: one screen that shows what is happening right now, across systems that were never designed to talk to each other. The temptation is to buy a BI tool and point it at five APIs. That works until the first API changes shape, and then nobody can explain why yesterday's number moved.

The architecture below is the one I keep coming back to. n8n handles ingest and alerting, Postgres holds the truth, and a React front end does the drawing. I used this shape on the Indonesia livestock operations dashboard, where operators drill from province-level clusters down to individual farm units on a live map.

What does an n8n dashboard architecture actually look like?

An n8n dashboard splits into four layers with hard boundaries between them: ingest, store, serve, alert. Each layer can be rebuilt without touching the others, which is the entire point.

The failure mode I see most often is a single n8n workflow that fetches, transforms, calculates and emails a summary. It works for a week. Then someone asks for last quarter's numbers and there is nothing to query, because the data was never stored.

That last rule matters more than it sounds. If the alerting workflow recomputes its own version of a metric, you will eventually get an alert that contradicts the dashboard, and the team stops trusting both.

Why n8n should not be your dashboard front end

n8n is an execution engine, not a query engine. Its job is to run a graph of nodes once and finish. A dashboard needs to answer arbitrary questions repeatedly, at low latency, for many concurrent viewers, which is the opposite workload.

People try to shortcut this with a webhook node that returns JSON to a chart library. It demos beautifully. Then the workflow gets hit ten times a second, every request burns an execution, and your instance queue backs up behind a nightly sync. If you are self-hosting, that cost lands directly on your infrastructure bill, which I break down in self-hosting n8n: costs and trade-offs.

"If a page refresh triggers a workflow execution, you have built a very expensive database driver."

Postgres already does concurrent reads, indexes, aggregates and connection pooling. Let it. n8n writes; the database serves. That single boundary removes most of the scaling problems before they exist.

How do you model the tables so the dashboard stays fast?

Store facts append-only with a natural key, and compute every dashboard number in a view. Never let n8n write a pre-aggregated KPI row, because you can never recompute it when the definition changes.

Fact tables that survive a replay

Each row is one observation from one source at one moment. The unique constraint spans the entity, the observation time and the source. Re-running yesterday's ingest then updates rows instead of duplicating them.

-- One row per observation. Nothing is ever silently replaced.
create table farm_metrics (
  id           bigint generated always as identity primary key,
  farm_id      text        not null,
  captured_at  timestamptz not null,
  head_count   int,
  feed_kg      numeric,
  source       text        not null,
  ingested_at  timestamptz not null default now(),
  unique (farm_id, captured_at, source)
);

create index on farm_metrics (farm_id, captured_at desc);

-- n8n upserts on the natural key, so a replayed run is a no-op.
insert into farm_metrics (farm_id, captured_at, head_count, feed_kg, source)
values ($1, $2, $3, $4, 'n8n:daily-sync')
on conflict (farm_id, captured_at, source) do update
  set head_count  = excluded.head_count,
      feed_kg     = excluded.feed_kg,
      ingested_at = now();

Views for anything the dashboard renders

Plain views are fine while tables are small. Once a chart scans millions of rows, move to a materialized view and refresh it from the same n8n schedule that runs the ingest. PostgreSQL supports REFRESH MATERIALIZED VIEW CONCURRENTLY when the view has a unique index, so readers are not blocked during the refresh.

The practical rule: if a query takes longer than roughly a quarter second in the SQL editor, it does not belong in a live tile. Materialize it, index it, or narrow the window. Heavier modelling work belongs in a proper pipeline, which is where my data engineering work usually starts.

How do you get data from n8n into Postgres reliably?

Use one workflow per source, write with the Postgres node in upsert mode, and make every run idempotent. Reliability here is mostly about assuming the workflow will be re-run, half-succeed, or fire twice.

That ingest_runs table is the unglamorous piece that saves you. A dashboard showing stale data with no warning is worse than a dashboard that is down, because nobody knows to distrust it. I put a per-source freshness strip along the top of every ops dashboard I build. If you are new to error branches and retries, start with the n8n automation tutorial for beginners and come back.

Serving the dashboard with React and Supabase

The front end talks to Postgres directly through Supabase's auto-generated REST API, with row level security deciding what each operator can see. There is no bespoke backend in the middle, which removes an entire deployable.

On the livestock build the stack was React with TypeScript, Recharts for the financial and margin charts, Leaflet for the geospatial layer, and Supabase for storage and auth. Google Gemini powered a streaming chat assistant over the same views, so the AI answered from the numbers the operator could see rather than from a separate extract.

One caveat worth knowing before you wire up realtime everywhere. Supabase's documentation notes that Postgres Changes authorizes every event against each subscriber, so a single write to a table with 100 subscribed users triggers 100 authorization checks, and changes are processed on a single thread to preserve ordering. Throughput therefore scales with subscriber count, not with your compute size. For high fan-out, their docs point you at Broadcast instead. More detail on the platform side sits on my Supabase integration page.

How do you add anomaly alerts without alert fatigue?

Alert on deviation from a rolling baseline rather than on a fixed threshold, and route by severity. A second n8n workflow runs on a schedule, queries the same views the dashboard reads, and decides whether anything is worth a human's attention.

Fixed thresholds fail in both directions. Set them tight and the channel becomes noise everyone mutes. Set them loose and you miss the slow drift that actually costs money. A rolling mean and standard deviation over a trailing window, computed in SQL, adapts as the operation grows.

Two rules keep this usable. First, deduplicate: an alert already open for the same entity and metric updates the existing message instead of posting a new one. Second, always include a link straight to the filtered dashboard view, so the responder lands on the chart rather than on the home screen.

What does an n8n dashboard cost to run?

Cost splits into three lines that scale on different axes: workflow executions, database compute and storage, and front-end hosting. The dashboard reads are usually the cheapest part, because they never touch n8n.

The number that surprises teams is executions. Vendors meter workflow runs, so a workflow polling every minute costs the same whether it moves one row or ten thousand. Batching is the single biggest lever. If you are still choosing a platform, the trade-offs are laid out in n8n vs Zapier vs Make.

When this architecture is the wrong choice

Skip it if your data already lives in one system that ships a decent dashboard. Building an ingest layer to duplicate what Shopify, HubSpot or your ERP already renders is work with no payoff.

Logistics and field operations hit all four regularly, which is why most of these builds land in logistics and supply chain teams. If you want the ingest layer designed alongside the rest of your automation, that is what my n8n build work covers.