--- title: "MySQL Integration" description: "Connect AI agents to MySQL and MySQL-compatible servers such as MariaDB, PlanetScale, and Aurora. Agents run parameterized SQL, do CRUD without SQL, inspect schemas, and bulk-load rows." url: https://flowrunner.ai/integrations/mysql date_modified: 2026-08-01T02:40:32-07:00 --- # MySQL [Database](https://flowrunner.ai/integrations/category/databases-warehouses) Connect AI agents to MySQL and MySQL-compatible servers such as MariaDB, PlanetScale, and Aurora. Agents run parameterized SQL, do CRUD without SQL, inspect schemas, and bulk-load rows. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 9 actions · Basic auth · available [MySQL website](https://mysql.com/) · [Platform Documentation](https://dev.mysql.com/doc/) · Capability data verified 2026-08-12 1. A flow step needs to update application records after an external event 2. Agent runs Select Rows to load the current state of the affected records 3. Agent confirms the incoming change is consistent with what the table holds 4. Agent identifies which rows are safe to write and which are ambiguous 5. Agent runs Update Rows with an explicit Where object for the safe matches 6. The owning team gets a summary of what changed via Slack 7. Any write to a production table above a row threshold pauses for approval ## What This Integration Enables Agents read and write MySQL data as steps in a flow, run arbitrary SQL for the cases the row helpers do not cover, and inspect structure with Get Table Schema and List Tables so they adapt to your schema. MySQL has no `RETURNING` clause, so writes return `insertId`, `affectedRows`, and `changedRows` rather than the full row; when an agent needs the database-generated values, it follows the write with Select Rows. The connect-per-call model keeps every step isolated, with no cached connections between runs. ### Without FlowRunner **App-only access**: The only way to change a record is through the application UI, one at a time **Unbounded writes**: An UPDATE with a forgotten WHERE rewrites every row in the table **No write status**: After a batch write there is no clean record of what changed ### With FlowRunner **Governed batch writes**: Rows are read and written as named flow steps with a full run log **Writes require a Where**: Update Rows and Delete Rows refuse to run without an explicit filter **Change is visible**: Every write returns matched and changed counts the agent can act on ## Use Case Scenarios ### Event-driven record updates An external event fires an upstream flow. The agent calls Select Rows to load the affected records, decides which are safe to change, and calls Update Rows with an explicit Where object, reading back `affectedRows` and `changedRows` to confirm exactly how many rows moved. The team stops making one-off edits through the app UI and lets the flow apply consistent changes. ### Idempotent import from an API Records arrive from another connector as an array. The agent calls Insert Rows to bulk-load them, or Upsert Row keyed on the table's primary or unique key when the run needs to be safe to repeat. Re-running the flow updates existing rows rather than creating duplicates. ### Status sync with a human gate The agent processes records in batches, marking each with a status after it writes. When a write would touch a production table above the configured threshold, the agent does not proceed on its own. It routes the write for approval and resumes only after a person confirms. ## Human-in-Loop Highlight A bulk UPDATE or DELETE against a production MySQL table is the kind of action that is trivial to run and painful to reverse. 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 `orders` matches 2,140 rows. Here is the Where object and a sample. Approve, edit the filter, or cancel?" The write runs only after a person confirms, with the approver and timestamp captured in the run log. A connector can run any SQL; an orchestration layer 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 single SQL statement (SELECT, INSERT, UPDATE, DELETE, DDL, CTEs) with \`?\` placeholders bound via the Parameters array, and returns rows and field metadata for reads or \`affectedRows\`, \`insertId\`, and \`changedRows\` for writes. Use it for the intentional cases the row helpers do not cover. ### Rows 6 - **Select Rows** Reads rows without writing SQL, with column selection, equality filters, ordering, and limit and offset pagination. - **Insert Row** Inserts one row from a JSON object and returns \`insertId\`, \`affectedRows\`, and an echo of the data. - **Insert Rows** Bulk-inserts an array of row objects in a single statement and returns the inserted count and the first auto-increment id. - **Update Rows** Updates rows matching a non-empty Where object and returns \`affectedRows\` (matched) and \`changedRows\` (actually modified). A Where object is required to prevent a full-table write. - **Delete Rows** Deletes rows matching a non-empty Where object and returns \`affectedRows\`. A Where object is required to prevent a full-table delete. - **Upsert Row** Runs \`INSERT ... ON DUPLICATE KEY UPDATE\` keyed by the table's primary or unique indexes. Use it to keep a table in sync with an external source across repeated runs. ### Schema 2 - **Get Table Schema** Returns column names, full types, nullability, defaults, key membership, and extra attributes from \`information\_schema.columns\`. - **List Tables** Lists all tables and views in the current database, for schema discovery without hardcoded configuration. ## Frequently Asked Questions ### What can FlowRunner do with MySQL? FlowRunner agents can run Execute Query, Select Rows, and Insert Row in MySQL, plus 6 more actions. ### Does connecting MySQL to FlowRunner require OAuth? No. MySQL connects to FlowRunner with basic authentication (a username and password), no OAuth flow required. ### Can MySQL trigger a FlowRunner workflow automatically? MySQL doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at MySQL?** This integration exposes MySQL 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/mysql. Site index: https://flowrunner.ai/llms.txt