--- title: "Xata Integration" description: "Let AI agents work your Xata serverless Postgres data. Agents insert, update, and bulk-load records, run typed queries, full-text search across tables and branches, aggregations, summaries, and raw SQL." url: https://flowrunner.ai/integrations/xata date_modified: 2026-08-01T02:40:32-07:00 --- # Xata [Database](https://flowrunner.ai/integrations/category/databases-warehouses) Let AI agents work your Xata serverless Postgres data. Agents insert, update, and bulk-load records, run typed queries, full-text search across tables and branches, aggregations, summaries, and raw SQL. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 13 actions · API key · available [Xata website](https://xata.io/) · [Platform Documentation](https://xata.io/docs) · Capability data verified 2026-07-27 1. The nightly sync from the order system finishes exporting 2. Bulk Insert Records loads the incoming rows in a single request, with Xata generating ids 3. Aggregate Records reconciles row counts and totals against the source system's figures 4. Query Table pulls the specific records behind any mismatch for inspection 5. The agent drafts the corrective SQL and rehearses it with Run SQL on a working branch to measure affected rows 6. The data owner reviews the statement and its affected-row count before it runs against main 7. The reconciliation summary posts to \[Slack\](/integrations/slack) ## What This Integration Enables Xata's bet is that Postgres should behave like a product: serverless, branchable, searchable, with typed data APIs alongside raw SQL. That combination is what makes it a database agents can work responsibly. A FlowRunner agent gets structured record operations for the routine writes, filter queries and full-text search for the reads, aggregations and summaries for the reporting, and parameterized SQL for everything the structured API cannot express. Branches are the safety architecture: what would be a scary statement on production becomes a rehearsal on a copy, and the [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) approval happens with evidence in hand. - Insert, upsert, update, and bulk-load records with schema-matched JSON - Query with structured filters and run fuzzy full-text search across one table or the whole branch - Compute counts, sums, averages, and grouped summaries for reporting without an export - Execute parameterized Postgres-compatible SQL for joins and advanced work ### Without FlowRunner **Every question is a ticket**: Operational data exists, but answering from it means finding an engineer with console access **Imports are one-off scripts**: Each load is a bespoke loader with no validation and no record of what it did **Fixes run raw against production**: Corrective SQL gets pasted into a console late in the day, WHERE clause willing ### With FlowRunner **Agents answer from the data**: Queries, aggregations, and grouped summaries run on schedule and land where people read **Loads reconcile themselves**: Every bulk insert is followed by an aggregate check against the source totals **Writes are rehearsed**: Statements prove out on a branch with row counts shown, and a person approves the run on main ## Use Case Scenarios ### The metrics digest nobody compiles Each morning the agent runs Summarize Records on the orders table, grouped by status and channel with sums and averages per group, plus Aggregate Records for the day's headline counts. The result posts to [Slack](https://flowrunner.ai/integrations/slack) as a digest and appends to [Google Sheets](https://flowrunner.ai/integrations/google-sheets) for the running history. When a number looks off, the follow-up is immediate: Query Table with the same filter pulls the underlying records into the thread, so the conversation happens over rows, not recollections. ### External systems synced without column loss Rows flow in from [Google Sheets](https://flowrunner.ai/integrations/google-sheets) and the order platform. For records keyed on an external id, the agent deliberately avoids Create or Replace Record for routine syncs, because a replace clears every column the payload omits. Instead it uses Update Record with upsert enabled: existing rows get partial updates that preserve untouched columns, and missing rows get created. Full replaces are reserved for loads that genuinely own the whole record, and Bulk Insert Records handles first-time imports at volume. ### One search box over every table Support gets a customer email and needs everything: orders, tickets, shipments, notes. The agent runs Search Branch with the customer's email and name, and gets back relevance-ranked records tagged with their source table, across the entire branch in one call. The assembled picture posts into the support thread within seconds, and for compliance and data-subject requests the matched records archive to [S3](https://flowrunner.ai/integrations/s3) as a dated, auditable bundle. Nobody writes a five-table join to answer a routine lookup ever again. ## Human-in-Loop Highlight Run SQL executes whatever statement it is given against the branch, and on main that includes the UPDATE with the missing WHERE clause that rewrites a column for every row in the table. Delete Record is explicit about being permanent, and Create or Replace Record silently clears any column the payload leaves out, which is data loss wearing an upsert's clothing. The FlowRunner posture uses Xata's own architecture as the gate: destructive statements rehearse on a working branch first, the agent reports exactly how many rows the statement touched there, and the run against main waits for the data owner to read the statement and the count and say so. A database that makes branching cheap has removed every excuse for unrehearsed writes to production. 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 13 actions ### Records 7 - **Insert Record** Inserts a record with Xata generating the id, from a JSON object matching the table schema. The default write for new rows. - **Create Record** Creates a record with a specific id and fails if that id exists. The guarantee to reach for when overwriting would be the bug. - **Create or Replace Record** Upserts by id, fully replacing an existing record. Columns not in the payload are cleared, so it belongs to loads that own the whole record. - **Get Record** Retrieves a record by id, with column selection including dot notation into linked tables like author.name. - **Update Record** Partially updates only the provided columns, optionally creating the record if it is missing. The safe default for syncs. - **Delete Record** Permanently deletes a record by id, optionally returning selected columns of what was removed. Behind confirmation, always. - **Bulk Insert Records** Inserts many records in one request with generated ids. The import primitive for seeds and nightly loads. ### Query 1 - **Query Table** Queries with structured filter objects, sorting, column selection, and cursor or offset pagination. The read behind reporting and record inspection. ### Search 2 - **Search Table** Fuzzy full-text search over one table's searchable columns, relevance ranked, with prefix matching and column boosting. - **Search Branch** Full-text search across every table in the branch at once, results tagged with their source table. The one-call customer lookup. ### Analytics 2 - **Aggregate Records** Computes counts, sums, averages, min and max, unique counts, and date histograms, optionally filtered. The reconciliation and dashboard primitive. - **Summarize Records** Groups records SQL-GROUP-BY style with per-group summary functions, filterable and sortable on the output. One row per group, ready for a digest. ### SQL 1 - **Run SQL** Executes raw Postgres-compatible SQL with $1, $2 parameter placeholders against the branch. Joins, advanced aggregations, and the corrective statements that only run on main after a person approves. ## Frequently Asked Questions ### What can FlowRunner do with Xata? FlowRunner agents can run Insert Record, Create Record, and Create or Replace Record in Xata, plus 10 more actions. ### Does connecting Xata to FlowRunner require OAuth? No. Xata connects to FlowRunner with an API key, no OAuth flow required. ### Can Xata trigger a FlowRunner workflow automatically? Xata doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Xata?** This integration exposes Xata 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/xata. Site index: https://flowrunner.ai/llms.txt