Query your Postgres database from a workflow
Run parameterized SQL against Postgres from a workflow and act on the rows: alerts, AI summaries, approvals, writes back. Connects with DB credentials.
- Category
- Data & databases
- Connect
- Enter the connection details · managing connections
- Operations
- 4
- Triggers
- none yet
Your production database already knows the answer to most operational questions: which trials expire this week, which orders are stuck, which accounts went quiet. The Postgres integration lets a workflow ask those questions with real SQL over a direct connection and act on the rows: post them to Slack, run them through an AI agent, email a digest, or write a result back. Bulk updates and deletes can wait for a yes from a person first, and every run records each step's rows in and rows out, so a wrong update traces back to the query and input that caused it. Describe the job in plain English and MadMax writes the parameterized query, wires the connection and runs the step against your database during the build so you see real rows before anything is scheduled.
What teams build
- An 8 am schedule runs
execute_queryfor trials ending within three days, a loop hands each row to an AI agent that drafts a specific note from the account's usage columns, send email delivers it, andupdate_rowstampslast_contacted_at. - Every 30 minutes a query finds orders stuck in
processingfor over two hours, the list is posted to Slack, and an approval asks ops whether to auto-cancel; on approve,update_rowsets them tocancelledand customers are notified. - A signup webhook runs an AI classifier for industry and size, a query checks for an existing row by email, and an if step chooses
update_roworinsert_row.
How it connects
Fill in host, port, database name, username and password, and turn on Require SSL for managed providers (RDS, Neon, Render, Fly and similar need it). The host must be reachable from MadMax, and a read-only database user is a good first connection. Credentials are stored encrypted and never rendered back; changing the password is a reconnect on the same connection. Table and column names are validated and values are always bound as $1, $2, … parameters, so data from a form or a webhook never gets interpolated into the SQL string. See managing connections.
Related
Every Postgres operation MadMax can run
Straight from the integration's manifest, so this list is what the steps on the canvas can actually do today.
| Operation | What it does |
|---|---|
| delete row | Delete rows matching all columns in the WHERE clause. Returns the number of rows affected. |
| execute query | Run an arbitrary SQL statement with parameterized values. Reference parameters in the SQL as `$1`, `$2`, ... in order. Returns rows + column names + affected row count. |
| insert row | Insert a single row into a table. Returns the inserted row. |
| update row | Update rows matching all columns in the WHERE clause. Returns the updated rows. |
Works with
Describe the workflow. MadMax builds it and tests it on your data.
Free to start, no card. Connect your apps, say what should happen in plain English, and watch each step run against real data before anything goes live.