Integration guide

Postgres integration for AI agents and workflows

Swfte Studio has a Postgres node. Its shipped data shows two actions: list the tables in a schema and run a query. The MCP tool list also has a Postgres server that asks for a DATABASE_URL. The safest way to let a workflow into your database is a read-only role, with a person approving any query that is not fixed in advance.

The catalogue lists the entry as Postgres, under development and data-storage. The shipped template calls the node POSTGRESQL, and it is the only template that uses it. This page follows the template for what the node does.

Built in Swfte Studio, run as a governed workflow, and held to the same rules as any governed agent.

Postgres at a glance

Catalogue
Development, Data Storage
Actions in the shipped data
2 (1 read, 0 write, 1 other)
Credential type shown
A stored credential, referred to by id
MCP server
Postgres, needs DATABASE_URL
Shipped templates that use it
postgresql data analysis

What you can do with Postgres

Every action below is read from a node in a shipped workflow template. Nothing is listed that the data does not show.

Postgres actions in the shipped workflow templates
ActionTypeOperationWhat the data shows
List Database TablesReadlist_tablesLists the tables in a schema. The template uses the public schema.
Query Sample DataDepends on the rolequeryRuns a query given as text. The template’s query is read-only, but the action takes any text, so what it can do depends on the database role.

The query action is the one to treat with care. In the template it asks the information schema for table sizes. In your workflow it will run whatever text reaches it, within the limits of the role.

The template starts without a database event. Change notifications, such as a row being inserted, are not in the data: <Postgres trigger events - founder to fill>.

A query is code, and the database does what it says

There is a large difference between a model summarising a table and a model writing the SQL that reads it. A fixed query can be reviewed once. A generated query can be anything the database user is allowed to do. The shipped template stays on the safe side: it lists the tables in the public schema and runs one fixed query for the ten largest tables by size, taken from the information schema.

A read-only database role is the best guard you have, because it holds even if everything above it fails. Add the approval of the exact query text on top of it, so that the person approving sees what will run and not a description of it.

How to connect Postgres

The MCP tool entry asks for DATABASE_URL, a connection string. The shipped template points at a stored credential by id, and the credential type is not in the data: <Postgres credential type - founder to fill>.

  1. 01

    Create a read-only role

    In Postgres, make a role that can only select, and grant it on the schemas the workflow needs. Do not reuse an application login.

  2. 02

    Limit it to schemas

    List the schemas the role may read and leave out the ones that hold people, payment or credential data.

  3. 03

    Point it at a replica if you have one

    A replica keeps analytical queries away from the database your application writes to.

  4. 04

    Gate the query text

    Where the query is not fixed, a human-input step shows the approver the exact SQL before it runs.

Three governed Postgres workflows to build in Studio

Each has a label. A starting point builds on a shipped template, which is an integration test with no approval step. A design is intent only.

Database size and shape note

Starting point

Builds on the shipped template “postgresql data analysis” (7 nodes), which you can find in the template library.

Give a platform team a short plain-English note on which tables are largest and what that suggests.

  1. List the tables in the public schema.
  2. Run the fixed size query.
  3. A code node formats the result as a short summary.
  4. An OpenAI chat call returns two or three observations, and an owner reads them in a human-input step.

Where the approval sits. The shipped template sends its summary to the model and moves on. The reader’s step and a read-only role are the additions.

Approved ad hoc query

Designed

Let an analyst ask a question in words and run the SQL only after seeing it.

  1. An agent turns the question into a SQL statement.
  2. A policy check denies statements that are not plain selects.
  3. A human-input step shows the analyst the exact SQL, with approve and reject branches.
  4. On approval, the query action runs it under the read-only role, and the rows go back as output.

Where the approval sits. The approval is on the SQL and not on the question, which is what makes it meaningful. The read-only role is the backstop if the check misses something.

Schema documentation draft

Designed

Draft a description of each table for a data catalogue, for the owner to review.

  1. List the tables in a schema.
  2. An LLM node drafts a one-line description of each from its name and the owner’s notes.
  3. A human-input step sends the draft to the data owner.
  4. The approved text is passed on as output, to be filed in the catalogue by a person.

Where the approval sits. Table names alone can mislead a model, so the owner’s review is where mistakes are caught. Nothing is written to the database.

Shipped template
A governed template with its approval step already in it ships in the platform.
Starting point
A shipped template runs the same actions. It is an integration test with no approval step, so you add the gate.
Designed
Design intent. It uses the actions listed above plus generic nodes, and nothing has been built as a template.

Approvals and records for Postgres

A database holds the facts a company runs on, so the controls start with what the role may touch.

Needs a person’s approval

  • Any query that was written by a model and has not been reviewed.
  • Any run that sends rows to a model, rather than counts or sizes.
  • Granting the role access to a new schema.

Can run without one

  • Listing tables in a schema the owner has agreed.
  • Running the fixed size query from the shipped template under a read-only role.

What is recorded

  • Each list and query action in a run, in order.
  • The approver’s decision on a query, and when they made it.
  • A policy decision on the statement, such as a deny on anything but a select.

The role is enforced by Postgres, the approval by the human-input step, and the check on the SQL by the policy engine, which acts on runs that have a policy attached. The run ledger records what ran. Treat the three controls as layers: the role is the last one standing.

A policy step in a design below describes the intent. The policy engine acts only on runs that have a policy attached, and a self-serve way to author policies is not something we describe as built.

Swfte’s own security position and any attestations are on the trust page. How approvals, policy and records fit together is on the governed agents page.

Comparing tools for Postgres work

These comparison pages are dated and sourced. Each says who should pick the other tool.

  • Retool alternatives

    The Retool comparison covers internal tools built on top of a database, which is a different shape from an agent workflow.

  • Windmill alternatives

    The Windmill comparison covers script-first workflows that run SQL on a schedule.

  • Best automation platforms

    How automation platforms compare on governance, approvals and records, with the method shown.

Postgres questions

Can an agent write SQL against my database?

It can if you let it, because the query action takes text. We recommend a read-only role, a policy check that denies anything but selects, and an approval step that shows the exact SQL before it runs.

Is there a Postgres MCP server in Swfte?

Yes. The MCP tool list has a Postgres entry that asks for DATABASE_URL. The tools it exposes are not in the data, so check what the server can do before you hand it to an agent.

Can the node change data?

The shipped template only reads. The query action runs whatever text it is given, so whether a write succeeds depends on the database role. Use a read-only role and the question does not arise.

How do I keep rows out of a model’s prompt?

Send counts and sizes in place of rows, redact identifiers with a policy rule before the model call, and have a person read the summary before it goes further. The shipped template sends a size summary, not row data.

Is there a Postgres template to start from?

One: postgresql data analysis, which lists tables, runs a fixed size query and asks an OpenAI model for observations. It is an integration test with no approval step and no redaction, so treat it as a starting point.

Build a governed Postgres workflow

Begin with a read-only workflow on a test account, then add one write with an approval in front of it.

Build this in Studio

Describe what you need in plain language. Studio builds the agents and workflows, and you keep every version.