Integrations · PostgreSQL

PostgreSQL AI agent integration

Give the agent typed, scoped, read-only access to a PostgreSQL replica so it can answer questions grounded in your live business data. Schema introspection, prepared statements, and per-tenant row-level security keep queries safe. The agent generates SQL against the schema you expose, runs it against a read replica, and formats the result for the conversation — without ever touching your write-path or leaking data across tenants.

How it works

Three steps to ship PostgreSQL in your pilot

STEP 1

Provision a read replica

Stand up a read replica with a least-privilege user. Grant SELECT only, restricted to the tables and columns the agent should see. Row-level security policies remain enforced; the agent inherits your governance model.

STEP 2

Expose a schema descriptor

Publish a schema descriptor that tells the agent what tables, columns, and relationships exist. The agent uses this to plan SQL — it never queries metadata catalogues at run time, so query cost stays bounded.

STEP 3

Run prepared statements

Generated SQL runs as prepared statements with parameter binding so injection risk is removed at the protocol level. Queries above a configurable cost budget abort; long-running statements time out and the agent retries with a smaller scope.

What teams use it for

Common PostgreSQL use cases

  • Customer-facing order lookups, balance queries, and shipment-status calls — answers grounded in live data, not stale exports.

  • Internal analytics chatbots for ops and product teams: ask in English, get a formatted answer plus the underlying SQL for audit.

  • B2B portal copilots that surface tenant-scoped account, billing, and usage data with row-level security enforced end-to-end.

Code preview

PostgreSQL — agent-generated query (audit-logged)

SQL
-- Agent: lookup most recent shipment for caller
PREPARE shipment_lookup (text) AS
  SELECT s.tracking_code,
         s.status,
         s.eta_at
  FROM shipments s
  WHERE s.customer_id = (
    SELECT id FROM customers WHERE phone = $1
  )
  ORDER BY s.created_at DESC
  LIMIT 1;

EXECUTE shipment_lookup('<caller-msisdn>');

Stylised example — not a runnable script. Endpoints, payload shapes, and authentication are documented in the integration runbook shipped during the pilot.

Frequently asked questions

Common questions

Does the agent ever write to the database?

By default, no. The recommended deployment grants SELECT only, and that's how every customer ships today. If a particular flow benefits from agent writes (e.g. logging a callback request), we scope a single tightly-bounded INSERT route with explicit approval — not a general write grant. The default is read-only.

How is SQL injection prevented?

All generated SQL runs as prepared statements with parameter binding — the protocol layer enforces a clean separation between statement and parameter. The agent never concatenates user input into a SQL string. Generated SQL is reviewed against the schema descriptor; statements outside the allowed surface are refused before execution.

Is row-level security supported?

Yes. The agent connects as a Postgres user whose role triggers your RLS policies — exactly the same way your application does. Multi-tenant deployments rely on this: the agent can only see data for the tenant whose conversation it's handling, even when the underlying tables hold all tenants' rows.

What about query cost and runaway statements?

Every query has a cost ceiling (configurable per deployment) and a wall-clock timeout. Statements that exceed either abort, and the agent retries with a narrower scope or offers to escalate. EXPLAIN output for generated queries is audit-logged for tuning. Long-running ad-hoc analytics are explicitly out of scope.

Ready to wire PostgreSQL into your pilot?

Pilot in 14 days. Live in 30.

A 30-minute scoping call. We bring the PostgreSQL integration patterns. You bring the system credentials and the first use case.

Talk to salesSee product capabilities