How DataQloo Compiles a Visual Workflow Into SQL

The canvas isn't a black box

When you build a workflow in DataQloo's Visual Designer, you're not configuring an opaque pipeline — you're building a query, one node at a time. An Input node picks the source table. A Filter node adds a WHERE condition. A Summarize node adds a GROUP BY and an aggregate. A Sort node adds an ORDER BY. The compiler walks the graph and assembles these into a single SQL statement, which you can read directly in the SQL tab of the results panel.

Why parameterization matters

Values from a Filter node — the West in Region = West, for example — aren't concatenated directly into the query string. They're passed as query parameters, the same way you'd write a safe, injection-resistant query by hand. This isn't a nice-to-have; it's the only way the compiler is written. There's no "fast path" that skips it.

A worked example

Suppose you want total revenue by region, for accounts marked active. On the canvas, that's an Input node (your accounts table), a Filter node (Status = active), a Summarize node (SUM(Revenue) grouped by Region), and a Browse node to see the result. The compiler turns that into roughly:

SELECT region, SUM(revenue) AS revenue
FROM accounts
WHERE status = $1
GROUP BY region

with active passed as $1. Nothing about that query is hidden from you — it's the same thing you'd see if you'd written it by hand.

Where this breaks down today

The compiler currently processes one node of each type meaningfully per workflow — it isn't yet walking arbitrary graph edges to support things like chained filters or multi-table joins. If your workflow needs more than one Filter node's worth of logic, that's a real limitation today, not a hidden one. It's tracked on the feature roadmap alongside the Join and Union nodes that would make multi-source workflows possible.