CloudFlow Datastore now runs SQL

Query, reshape, and maintain your Datastore tables with PostgreSQL, right inside a flow.

Datastore tables are good at remembering things between flow runs: which resources you already processed, per-account thresholds, when a job last ran. But the moment you wanted to compute something across that data, you hit a wall. Get, Insert, Upsert, and Delete can fetch and store rows, but they can't average a column, join two tables, or answer "is today's number unusual compared to the last 30 days?" That logic ended up in Code nodes or, more often, nowhere.

That gap is closed. The Datastore node has a new Run SQL action.

What you get

Run SQL executes a full PostgreSQL syntax statement against your Datastore tables in CloudFlow. You reference tables by name, and you bind values from earlier steps or flow variables with :name parameters, so a date computed by a Date/time transform drops straight into your WHERE clause. The editor validates the statement as you type, and for a SELECT it derives the output schema on the spot, so downstream nodes can reference each column before the flow ever runs.

It's not just SELECT. The action covers INSERT, UPDATE, and DELETE, plus the DDL you need for a self-maintaining table: CREATE TABLE, adding and dropping columns, and unique constraints. A flow can now create its own history table, aggregate over it, and prune rows older than its retention window, all with three small statements. Statements run under a restricted database role scoped to your organization's tables, and when you test a statement that modifies data, the editor asks you to confirm before it touches live rows.

Start with the tutorial

We built a working example that uses most of this in one flow: the Cost spike sentinel. It records yesterday's AWS spend per service into a Datastore table every morning, then a single SELECT with a CTE compares each service against its trailing 30-day average and returns only the services running more than 50% above baseline. A filter and a Slack notification turn that into an alert, and a DELETE keeps the table at 90 days of history. No external database, no warehouse job.

The Cost spike sentinel tutorial walks through building it from scratch, including the exact SQL.

Run SQL is available now to everyone with Datastore access in CloudFlow. If you build something with it, especially the kind of cross-run analysis that used to need an external database, tell us. The best feedback comes from real tables and real queries.