PostgreSQL

Connect AI agents to PostgreSQL. Agents run parameterized SQL, read and write rows without SQL, inspect schemas, and bulk-load records as governed steps in a flow.

9 actions available

An upstream flow step needs to reconcile records against the application database

Agent runs Select Rows to pull the candidate rows that need review

Agent reads the returned field values and joins them to the incoming data

Agent detects rows whose values conflict with the source of record

Agent runs Update Rows with an explicit Where object for the clean matches

Operations team receives a summary of what was reconciled via Slack

Any Update Rows or Delete Rows that would touch a production table above a row threshold pauses for approval

What This Integration Enables

Agents get bidirectional access to a PostgreSQL database as a first-class step in a flow. They read rows to make decisions, write results back, run arbitrary SQL for the cases the row helpers do not cover, and inspect table structure with Get Table Schema and List Tables so they adapt to your schema without hardcoded configuration. Because the connect-per-call model opens and closes a short-lived connection for each operation, every step is isolated and there are no stale or leaked connections between runs.

Without FlowRunner

SQL hidden in scripts Database updates live in cron jobs and one-off scripts no one owns

No guardrail on writes An UPDATE or DELETE with a missing WHERE quietly rewrites an entire table

Manual reconciliation Someone exports rows to a spreadsheet to compare against another system

With FlowRunner

Governed database steps Reads and writes happen as named steps inside a flow with a full run log

Writes require a Where Update Rows and Delete Rows refuse to run without an explicit filter

Agents handle the routine The agent reconciles clean matches and surfaces only the rows that need judgment

Use Case Scenarios

Cross-system reconciliation

An agent runs a nightly reconciliation between the application database and the billing system. It calls Select Rows to pull invoices marked open in PostgreSQL, compares them against the payment records returned from another connector, and for every clean match it calls Update Rows with an explicit Where object to mark the invoice reconciled. The controller stops sorting transactions by hand and starts the day looking only at the rows the agent could not match cleanly.

API-to-database sync

Records fetched from an external service arrive as an array. The agent calls Insert Rows to bulk-load them in a single statement, or Upsert Row keyed on a conflict column when the run needs to be idempotent. Re-running the flow never creates duplicates, because the upsert updates the existing row instead of inserting a second copy.

Schema-aware enrichment with a human gate

Before writing computed results back, the agent calls Get Table Schema to confirm the target columns exist and match the expected types. When a write would modify rows in a production table above the configured threshold, the agent does not proceed on its own. It pauses and routes the write for approval, then resumes the moment a human confirms.

Human-in-Loop Highlight

The riskiest thing an agent can do against a relational database is a bulk write with no easy undo. FlowRunner's answer is human-in-the-loop, an execution pattern where the agent pauses on its own, assembles the context and the choices, routes to a human on their preferred channel, and resumes the moment they respond. When an Update Rows or Delete Rows would affect more rows than the configured threshold, or would write to a table flagged as production, the agent pauses before executing and asks through Slack: "This Delete Rows on `public.invoices` matches 4,812 rows. Here is the Where object and a sample of the affected records. Approve, edit the filter, or cancel?" The write only runs after a person confirms, and the approver and timestamp are captured in the run log. That is the difference between a connector that can run any SQL and an orchestration layer that knows which SQL should stop and ask.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via Slack

Human decides

Agent resumes with decision

Agent Capabilities

9 actions

SQL

Execute Query Runs any SQL statement (SELECT, INSERT, UPDATE, DELETE, DDL, CTEs) with `$1, $2` placeholders bound via the Parameters array, and returns rows, the affected count, and field metadata. Use it for the intentional cases the row helpers do not cover, including deliberate unconditional writes.

Rows

Select Rows Reads rows without writing SQL, with column selection, equality filters, ordering, and limit and offset pagination. Use it when an agent needs to query application data before making a decision.
Insert Row Inserts one row from a JSON object and returns the inserted row via `RETURNING *`. Use it to append a single record without hand-writing an INSERT.
Insert Rows Bulk-inserts an array of row objects in a single statement. Use it to load records fetched from an API or another service in one efficient write.
Update Rows Updates rows matching a non-empty Where object and returns the updated rows. A Where object is required, so a full-table write cannot happen by accident.
Delete Rows Deletes rows matching a non-empty Where object and returns the deleted count. A Where object is required to prevent an accidental full-table delete.
Upsert Row Runs `INSERT ... ON CONFLICT ... DO UPDATE` keyed by the given conflict columns. Use it to keep a table in sync with an external source so re-runs never duplicate rows.

Schema

Get Table Schema Returns column names, types, nullability, defaults, and positions from `information_schema.columns`. Use it so an agent can inspect a table before reading or writing it.
List Tables Lists all tables and views in user schemas, with system schemas excluded, for schema discovery without hardcoded configuration.

Start building with PostgreSQL

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us