ClickHouse
Read queries, write/DDL, insert records, and create-table-if-not-exists against ClickHouse over its HTTP interface, with named typed {name:Type} parameters and double-brace {{$.path}} mustache tokens pulled from the flow. Tuned for analytics workloads.
- SDK
- Node
- Protocol
inflowv1- Actions
- 4
- Version
- v0.1.0
- Author
- Inflowenger
- Runs on
- Any
inflowv1host - Categories
- AnalyticsDatabases and stores
Reach for it when
Many rows, asked questions repeatedly — events, logs, metrics, anything you'll want a GROUP BY over.
The use people don't expect
A flow that writes its own execution facts to ClickHouse becomes measurable: how often that branch is taken, how long approvals really sit, which rule fires most. You're querying the process, not just its subjects.
A flow that uses it
Each one is a shape of flow, not a template to copy. Node names are the labels as they appear on the canvas; a name with a slash means either would do.
The process measuring itself
Starts withEvery run of a flow that matters.
- CLICKHOUSE
Each decision point appends a row: which branch, what input, how long.
- CLICKHOUSE
A weekly read asks which path dominates and where the time goes.
- Gmail / Telegram
The answer goes to whoever owns the process.
What you getProcess improvement stops being a workshop exercise. You change the graph because a query told you which edge is slow.
The reference, not the pitch
This page is about what the plugin is for. Every action, every connection field, the ports, the install one-liner and the caveats are in the catalog entry, which is the thing the maintainer updates.
Near it in the catalog
The data is files — CSV, Parquet, JSON, Excel — on disk, over https, or in a bucket. SQL over them in place.
MSSQLMicrosoft SQL ServerSQL Server or Azure SQL — including the branch instance that legally cannot leave the building.
MONGODBMongoDBDocuments whose shape you don't want to declare up front.