Before you pick where things run, decide how data is handled.
Data plane — start here
Before you pick where things run, decide how data is handled. Two stores come built into every FlowFuse server install — the Team Broker and relational Tables — exposed to every instance with nothing extra to stand up. Everything else you bring your own: run it (a time-series DB, an existing database, a model) and expose it to the community over Project Link, no inbound ports. This is the data plane the architectures on the next pages all sit on.
Built in
Ships with every FlowFuse server install; exposed to every instance.
Instances on the team
Instance
App A
Instance
App B
Instance
App C
query & update
Built into every FlowFuse server install
FlowFuse Tables
relational
Authenticated · every instance reaches it
A place for records that relate to each other — assets, config, users, orders — that you look up, join and update in place. It's FlowFuse Tables, built into every FlowFuse server install and exposed to every instance on the team.
Use it when
The data has structure and relationships, and apps across the team should read and write the same store.
How it works
FlowFuse Tables (managed PostgreSQL) via the Query node; because it ships with the server, any instance on the team reaches it natively over an authenticated connection. External systems can read it too.
In FlowFuse
FlowFuse Tables — managed PostgreSQL, built into every FlowFuse install
Query node — read, join and update from any instance
Exposed to the whole team automatically — nothing to stand up
Also any external Postgres — same node
Watch out
Not for high-rate timestamped streams; use the time-series target for those.
Built in
Ships with every FlowFuse server install; publish once, many subscribe.
Publisher
Instance
publishes
publish
Built into every FlowFuse install
Team Broker
built in · UNS
subscribe
Subscribers
Dashboard
subscribes
Historian
subscribes
Other app
subscribes
MQTT · publish once, many subscribe
A real-time bus, not storage: one instance publishes to a topic, any number subscribe. It's the Team Broker, built into every FlowFuse server install — the backbone of a Unified Namespace.
Use it when
Live data needs to reach many consumers at once, decoupled, as it happens.
How it works
The built-in Team Broker with publish / subscribe nodes; because it ships with the server, every instance on the team can publish and subscribe over MQTT. Pair with Tables when you also need to keep history.
In FlowFuse
Team Broker — built into every FlowFuse install, no separate product to stand up
publish / subscribe nodes
Topic structure — your Unified Namespace
Exposed to the whole team; pair with Tables for history
Watch out
It carries data, it doesn't store it; write to Tables too if you need history.
Bring your own
External today; FlowFuse has no built-in time-series DB.
External · where the readings live
Time-series DB
Timescale / QuestDB
Postgres wire
Fronted by the platform
Hosted Instance
connects & fronts it
Project Link
Instances that query it
Instance
query by time
Instance
query by time
Instance
query by time
Postgres wire
Project Link · target is a Hosted Instance
A store built for a steady stream of timestamped readings — sensor data, telemetry, trends — written fast and queried by time. FlowFuse has no built-in time-series database, so you run one and expose it to the fleet.
Use it when
The data is a continuous stream of timestamped values, written at high rate and queried by time window.
How it works
Run TimescaleDB, QuestDB or InfluxDB where you want. A Hosted Instance connects to it — Timescale and Quest speak the Postgres wire, so the Query node connects exactly like Tables — and fronts it; other instances reach it over Project Link, which always calls a Hosted Instance, with no inbound ports.
In FlowFuse
External — FlowFuse has no built-in time-series DB today
TimescaleDB / QuestDB — speak the Postgres wire; Query node connects like Tables
Hosted Instance — connects to it and fronts it for the fleet
Project Link — reaches it with no inbound ports (targets a Hosted Instance)
Watch out
Not part of FlowFuse; you run and expose it. Pair with the Team Broker for live + history.
Bring your own
Expose any other store or service to the fleet over Project Link.
Wherever it lives · you run it
Your store / service
SQL · ML · gateway
connects
Fronted by the platform
Hosted Instance
connects & fronts it
Project Link
Instances that query it
Instance
queries it
Instance
queries it
Instance
queries it
connects
Project Link · target is a Hosted Instance
Any other store or service FlowFuse doesn't provide — an existing SQL database, an ML model, a site gateway. You run it where it already lives and expose it to the community of managed instances over Project Link, with no inbound ports.
Use it when
You need to reach a store or service that isn't built in and isn't a time-series DB — an existing database, a model, a gateway.
How it works
A Hosted Instance connects to the store or service and fronts it; other instances reach it over Project Link — which always targets a Hosted Instance — as a secure API / MCP endpoint, with no inbound ports and no copy into a warehouse.
In FlowFuse
Hosted Instance — connects to the store / service and fronts it
Project Link — calls a Hosted Instance (only Hosted Instances are callable targets)
Any SQL database, ML model or gateway
Exposed as a secure API / MCP endpoint, no inbound ports
Good for
Keeping data and services where they already live and exposing them securely to the fleet. FlowFuse doesn't care what the target is.
Calling one external endpoint from a flow — an HTTP request or webhook to one system — is a Node-RED decision, not a platform data target.
FlowFuse Application Guide