CloudFlow Datastore spricht jetzt SQL

Abfragen, Umformen und Pflegen Ihrer Datastore-Tabellen mit PostgreSQL – direkt im Flow.

Datastore-Tabellen sind gut darin, sich Dinge zwischen Flow-Läufen zu merken: welche Ressourcen Sie bereits verarbeitet haben, Schwellenwerte pro Konto, wann ein Job zuletzt gelaufen ist. Doch sobald Sie über diese Daten hinweg etwas berechnen wollten, stießen Sie an eine Grenze. Get, Insert, Upsert und Delete können Zeilen abrufen und speichern, aber sie können keinen Durchschnitt über eine Spalte bilden, keine zwei Tabellen verknüpfen und keine Frage wie "Ist der heutige Wert im Vergleich zu den letzten 30 Tagen ungewöhnlich?" beantworten. Diese Logik landete in Code-Nodes – oder, noch häufiger, nirgendwo.

Diese Lücke ist jetzt geschlossen. Der Datastore-Node hat eine neue Aktion: Run SQL.

Das steckt drin

Run SQL führt vollständige PostgreSQL-Statements auf Ihren Datastore-Tabellen in CloudFlow aus. Sie referenzieren Tabellen über ihren Namen und binden Werte aus früheren Schritten oder Flow-Variablen über :name-Parameter ein – ein von einer Date/time-Transformation berechnetes Datum landet also direkt in Ihrer WHERE-Klausel. Der Editor validiert das Statement bereits während der Eingabe, und bei einem SELECT leitet er das Ausgabeschema sofort ab, sodass nachgelagerte Nodes jede Spalte referenzieren können, noch bevor der Flow überhaupt läuft.

Und es bleibt nicht bei SELECT. Die Aktion deckt INSERT, UPDATE und DELETE ab – plus die DDL, die Sie für eine sich selbst pflegende Tabelle brauchen: CREATE TABLE, das Hinzufügen und Entfernen von Spalten sowie Unique Constraints. Ein Flow kann jetzt seine eigene Verlaufstabelle anlegen, darüber aggregieren und Zeilen löschen, die älter als sein Aufbewahrungsfenster sind – alles mit drei kurzen Statements. Statements laufen unter einer eingeschränkten Datenbankrolle, die auf die Tabellen Ihrer Organisation begrenzt ist. Und wenn Sie ein Statement testen, das Daten verändert, fragt der Editor zur Sicherheit nach, bevor es echte Zeilen anfasst.

Am besten mit dem Tutorial starten

Wir haben ein lauffähiges Beispiel gebaut, das das meiste davon in einem einzigen Flow vereint: den Cost spike sentinel. Er schreibt jeden Morgen die gestrigen AWS-Ausgaben pro Service in eine Datastore-Tabelle; anschließend vergleicht ein einziges SELECT mit einer CTE jeden Service mit seinem gleitenden 30-Tage-Durchschnitt und liefert nur die Services zurück, die mehr als 50 % über der Baseline liegen. Ein Filter und eine Slack-Benachrichtigung machen daraus einen Alert, und ein DELETE hält die Tabelle konstant bei 90 Tagen Historie. Keine externe Datenbank, kein Warehouse-Job.

Das Tutorial zum Cost spike sentinel zeigt Schritt für Schritt, wie Sie ihn von Grund auf bauen – inklusive des exakten SQL.

Run SQL ist ab sofort für alle mit Datastore-Zugriff in CloudFlow verfügbar. Wenn Sie etwas damit bauen – besonders die Art von Analyse über mehrere Läufe hinweg, für die früher eine externe Datenbank nötig war –, geben Sie uns Bescheid. Das beste Feedback entsteht aus echten Tabellen und echten Queries.