--- title: "Amazon Redshift Integration" description: "Run SQL against an Amazon Redshift cluster or serverless workgroup through the Data API, no persistent connection required. Agents execute statements and batches asynchronously, poll for completion, fetch typed result rows, and explore databases, schemas, and table columns." url: https://flowrunner.ai/integrations/aws-redshift date_modified: 2026-08-01T02:40:32-07:00 --- # Amazon Redshift [Database](https://flowrunner.ai/integrations/category/databases-warehouses) Run SQL against an Amazon Redshift cluster or serverless workgroup through the Data API, no persistent connection required. Agents execute statements and batches asynchronously, poll for completion, fetch typed result rows, and explore databases, schemas, and table columns. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 10 actions · Custom auth · available [Amazon Redshift website](https://aws.amazon.com/) · [Platform Documentation](https://docs.aws.amazon.com/redshift-data/latest/APIReference/Welcome.html) · Capability data verified 2026-08-12 1. A nightly reconciliation flags order rows in the warehouse that disagree with the billing system 2. Execute Statement runs the diagnostic SELECT that isolates the affected rows 3. Describe Statement polls until the query reports FINISHED 4. Get Statement Result fetches the typed rows, and the agent drafts the corrective UPDATE with the exact row count it will touch 5. The data owner receives the proposed SQL, the affected row count, and a sample of before values 6. The data owner reads the statement and either approves it, edits it, or kills the run 7. Batch Execute Statement applies the approved fix as a single transaction, so it lands whole or not at all 8. The completion status and final row count post to the data team channel with the statement Id for the audit trail ## What This Integration Enables Redshift is where the numbers that run the company actually live, and the Data API is the right way to let agents near it: statements execute asynchronously over HTTPS with no persistent connection, so a workflow submits SQL, gets a statement Id, polls Describe Statement until FINISHED, and fetches typed rows with Get Statement Result. That submit, poll, fetch pattern is exactly the shape of a FlowRunner flow, which is why this connector feels less like a database driver and more like a colleague who runs queries and reports back. The same action runs a SELECT and a DROP TABLE. That symmetry is the reason this page spends so much time on governance: read paths run autonomously, write paths run through people. - Run parameterized DML and DDL against provisioned clusters or serverless workgroups - Execute multi-statement batches as one transaction with Batch Execute Statement - Poll long-running queries and fetch results only when they finish, no held connections - Monitor, audit, and cancel in-flight statements across the account - Explore databases, schemas, tables, and column definitions before writing a single query ### Without FlowRunner **The warehouse waits for an engineer**: Every ad hoc question, export, or fix queues behind whoever holds the database credentials **Fixes run from a laptop**: Corrective SQL gets pasted into a client at 6pm, with no review, no transaction discipline, and no record **Long queries block the pipeline**: Tools that hold a synchronous connection time out on real warehouse workloads, so big jobs get babysat ### With FlowRunner **Queries become workflow steps**: Agents submit SQL through the Data API, poll to completion, and hand typed rows to the next step, no persistent connection held **Mutations carry a signature**: Every UPDATE and DDL change arrives as a proposal with a row count, and a named person approves it before it runs **Async is the default**: Submit, poll, fetch is the native pattern, so a 20 minute aggregation is just a longer wait between steps, not a timeout ## Use Case Scenarios ### The Monday metrics run nobody performs A schedule fires early Monday. The agent calls Execute Statement with the revenue rollup query, polls Describe Statement, and fetches the result set once it reports FINISHED. Rows land in [Google Sheets](https://flowrunner.ai/integrations/google-sheets) for the leadership dashboard, and a summary with week-over-week movement posts to [Slack](https://flowrunner.ai/integrations/slack). If the query fails, the error message from Describe Statement goes to the data engineer as a task instead of the meeting starting with a blank dashboard. ### Schema-aware extraction that does not guess An agent asked to pull churn cohorts does not assume the table layout. It calls List Schemas and List Tables to locate the analytics tables, then Describe Table to read the actual column names, types, and nullability before composing the query. When an upstream team renames a column, the workflow notices at the metadata step and asks a human which column replaced it, instead of silently producing wrong numbers for a quarter. ### The runaway query patrol Every fifteen minutes, List Statements pulls recent Data API activity. The agent flags statements still in STARTED beyond the team's runtime budget and posts the query text, duration, and submitter context to the on-call channel. The on-call engineer decides which get Cancel Statement and which are legitimate month-end jobs that deserve the compute. The patrol never kills anything on its own: it turns an invisible cost into a visible decision. ## Human-in-Loop Highlight Execute Statement does not distinguish between reading and destroying: the same action that runs a harmless SELECT will run an UPDATE that rewrites a million fact rows or a DROP TABLE that ends an analytics pipeline, and the Data API executes whatever it is given. So in FlowRunner workflows, mutation is a proposal, not an act. The agent isolates the problem, drafts the corrective SQL, runs the read-only version first, and presents the data owner with the statement, the row count it will touch, and sample rows as they stand today. Only after approval does Batch Execute Statement apply the change inside a single transaction, and the statement Id goes into the audit log with the approver's name next to it. Warehouse data is the version of reality your dashboards, forecasts, and board decks are built on. Rewriting it at machine speed is the easy part; deciding it should be rewritten belongs to a person. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 10 actions ### Statements 5 - **Execute Statement** Runs a single SQL statement, DML or DDL, asynchronously against a provisioned cluster or serverless workgroup, returning a statement Id and initial status. Supports named bind parameters and connects via Secrets Manager or temporary credentials. The workhorse for every query and, under a human gate, every mutation. - **Batch Execute Statement** Runs multiple statements in order as one transaction, returning a single batch Id. Sub-statement results are fetched with the batch Id plus a :N suffix. The right tool for fixes that must land whole or not at all. - **Describe Statement** Reports a submitted statement's status, from SUBMITTED through FINISHED, ABORTED, or FAILED, along with the error message, query text, row counts, and duration. The polling step between submit and fetch, and the audit view for anything that went wrong. - **Cancel Statement** Cancels a statement that is still SUBMITTED, PICKED, or STARTED. The action behind runaway query patrols, fired only after a person decides the query dies. - **List Statements** Lists Data API statements for the account, newest first, filterable by status and name. The monitoring and audit surface for everything agents have submitted. ### Results 1 - **Get Statement Result** Fetches the cached JSON result rows of a finished statement: column metadata plus typed records, with a nextToken for paging large sets. Called only after Describe Statement reports FINISHED with a result set present. ### Catalog 4 - **List Databases** Lists the databases available in the cluster or workgroup. The first step when a workflow spans more than the default database. - **List Schemas** Lists schemas in a database with SQL LIKE pattern filtering and cross-database scoping. - **List Tables** Lists tables with schema and table name pattern filters, returning each table's name, type, and schema. How agents find the right table instead of assuming it. - **Describe Table** Returns a table's column definitions: names, types, precision, nullability. The metadata check that runs before query composition, so workflows adapt to the warehouse as it is, not as it was. ## Frequently Asked Questions ### What can FlowRunner do with Amazon Redshift? FlowRunner agents can run Execute Statement, Batch Execute Statement, and Describe Statement in Amazon Redshift, plus 7 more actions. ### Does connecting Amazon Redshift to FlowRunner require OAuth? Amazon Redshift uses a custom authentication method to connect to FlowRunner. ### Can Amazon Redshift trigger a FlowRunner workflow automatically? Amazon Redshift doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Amazon Redshift?** This integration exposes Amazon Redshift 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/aws-redshift. Site index: https://flowrunner.ai/llms.txt