SQL Database Integration

AI Agents That Your Database, in Plain Language

AI agents that connect directly to your PostgreSQL or MySQL database, explore tables, answer plain-language questions about your data, and with approval, make the change you described, so the team stops queueing up the analyst.

Book a Demo View all integrations

Answers from your data without queueing the analyst or writing the JOIN

Teams using AgentTeams connect their app database and let the agent answer the ad-hoc questions that used to wait for someone with SQL.

The data lives in your database. The answers don't.

Product, support, and ops all have questions the data could answer in five minutes, if anyone had time to write the query. So the questions queue up behind the one engineer who knows the schema, and most of them never get answered.

3 days

Median wait for an ad-hoc query

Even a five-minute query queues behind a roadmap. By the time the answer comes back, the question has moved on.

78%

Of data questions never get asked

When asking takes longer than guessing, people guess. Decisions get made without checking the actual numbers, and the database becomes a place data goes in, not where decisions come out.

2.5 hours

Per engineer, per week, on data requests

Engineers context-switching to write one-off queries, explain what columns mean, or update a row 'just this once.' Time that doesn't ship anything.

How it works with SQL Database

Three steps to an AI team member that works alongside you in SQL Database.

Connect your database

Paste a connection string, or fill in host, database, user, password. The engine, PostgreSQL or MySQL, is detected automatically. Optionally add SSH-bastion details for private databases.

Scope what it can do

Read-only is the default. Pick which schemas the agent can see. Turn on writes only when you want them, and decide which actions need approval before they run.

Ask the database anything

From Slack or the dashboard, ask questions, request exploration, or describe a change. The agent writes the SQL, shows the result, and, for writes, waits on your approval.

Everything you need for safe, fast answers from your DB

From schema exploration to gated writes to SSH-tunnelled production access, the agent reads and acts the way a senior data-savvy teammate would.

Plain-language SQL

Ask 'How many active customers signed up in the last 30 days, broken down by plan?' The agent writes the SQL, runs it, and gives you the answer plus the query, so you can verify it or save it.

Schema-aware exploration

The agent reads your tables, columns, and relationships and uses them like a teammate who knows the schema. 'Which table holds subscription state?' gets a direct answer, not a guess.

Read-only by default

Out of the box, the agent can read but not write. The full surface, SELECT, EXPLAIN, schema introspection, is available. Mutations are off until you opt in.

Gated writes when you need them

Turn on writes for the agent and every UPDATE, INSERT, or DELETE goes behind an explicit approval. You see the SQL, the rows affected, and the rollback plan before anything runs.

Engine auto-detection

PostgreSQL or MySQL, one tile. Drop in a connection string and the agent detects the engine, validates the credentials, and stores exactly the SSL profile that worked, so the runtime never re-probes.

Connect via SSH bastion

Production databases shouldn't be public. Point the agent at your SSH bastion and it tunnels through, all queries forwarded over the bastion's private network. Your DB stays behind the firewall.

What teams use it for

Concrete examples of SQL Database agents in production today.

Product team, daily metrics

PMs ask 'How many users hit the new onboarding flow yesterday?' or 'Which features are the active accounts using?' and get an answer in chat, with the SQL attached. The analyst stops being the bottleneck for routine questions.

Customer support, fact-finding

Support reps ask 'When did this customer's plan change?' or 'Which workspaces are affected by this bug?' The agent queries the app DB directly and pastes the answer into the ticket, no engineer escalation for read-only lookups.

Ops, the safe one-off update

An ops manager needs to bump a feature flag for one customer, or correct a typo in a settings row. They describe the change, the agent writes the UPDATE, and the manager approves. The change is logged with the exact SQL that ran.

Frequently asked questions

Things people commonly ask before deploying an AgentTeams agent in SQL Database.

Which databases work?

PostgreSQL and MySQL today. The engine is detected automatically from the connection string scheme or by probing, you don't pick it. PostgreSQL drivers ship with the agent; MySQL is enabled too. Other engines are on the roadmap.

Is it safe? Can the agent break our database?

Read-only by default, so the agent literally can't change anything until you turn writes on. With writes on, every mutation runs behind an explicit approval, you see the SQL, the affected rows, and the rollback plan before anything executes. Every action is logged with the agent's name.

We don't expose our database publicly. Can we still use this?

Yes, that's the SSH-bastion option. Point the agent at your bastion host with an SSH key, and the agent tunnels through it. The database itself never has to be reachable from the public internet, only the bastion does.

How does the agent know our schema?

It introspects the schema on demand, reading information_schema or the equivalent. You can also point it at curated documentation (table descriptions, column-meaning notes) by adding them as agent knowledge, the way you'd onboard a new analyst.

What about secrets and credentials?

The connection details are stored encrypted at rest with AES-256-GCM and only decrypted when the agent runs a query. The password is never echoed back through the dashboard or to the agent's chat. The same goes for SSH private keys when you connect through a bastion.