--- title: "PostgreSQL Integration" description: "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." url: https://flowrunner.ai/integrations/postgresql date_modified: 2026-08-01T02:40:32-07:00 --- # PostgreSQL [Database](https://flowrunner.ai/integrations/category/databases-warehouses) 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. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 9 actions · Basic auth · available [PostgreSQL website](https://postgresql.org/) · [Platform Documentation](https://www.postgresql.org/docs/) · Capability data verified 2026-08-12 1. An upstream flow step needs to reconcile records against the application database 2. Agent runs Select Rows to pull the candidate rows that need review 3. Agent reads the returned field values and joins them to the incoming data 4. Agent detects rows whose values conflict with the source of record 5. Agent runs Update Rows with an explicit Where object for the clean matches 6. Operations team receives a summary of what was reconciled via Slack 7. 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 1 - **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 6 - **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 2 - **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. ## Frequently Asked Questions ### What can FlowRunner do with PostgreSQL? FlowRunner agents can run Execute Query, Select Rows, and Insert Row in PostgreSQL, plus 6 more actions. ### Does connecting PostgreSQL to FlowRunner require OAuth? No. PostgreSQL connects to FlowRunner with basic authentication (a username and password), no OAuth flow required. ### Can PostgreSQL trigger a FlowRunner workflow automatically? PostgreSQL doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at PostgreSQL?** This integration exposes PostgreSQL to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/postgresql. Site index: https://flowrunner.ai/llms.txt