When a customer calls and asks "where's my order?", the answer lives in your database - not in a script you can paste into an agent. Connecting your AI phone agent to your database means the agent looks up, and optionally updates, live records from your own Postgres or MySQL database in the middle of a call. It checks an order, confirms an appointment, or reads a balance from the same data your team already works from. Most platforms turn this into an engineering project: you write and host a server the model calls. Flowyte turns it into a guided connection - create a scoped database user, map the exact queries you want, and the agent answers from real data on the line. This guide shows how it works and how to set it up safely.
Key Takeaways
- Flowyte connects to your own PostgreSQL or MySQL database so the agent can look up and update live records mid-call - check an order, confirm an appointment, read back a balance.
- Setup is a guided connection, not a coding project: you generate a least-privilege database user, test and connect, scope the schema, then map each query as a Skill.
- The agent only runs queries you authored. Every Skill compiles to one frozen, parameterized statement, so it can never write arbitrary SQL or see the full schema.
- Reads are the default. A write is a single-row insert or an update by unique key, never bulk, and it stays disabled until you review and enable it.
- Tables and columns you block never reach the schema browser, the AI assistant, or any binding - the agent never sees data you scoped out.
- If your data lives in a spreadsheet instead of a database, use the Google Sheets Skill. The database connector is for Postgres and MySQL only.
What does connecting your agent to a database do?
It gives your agent live access to the records you already keep, so it can answer from real data instead of a canned script. Connect a PostgreSQL or MySQL database and the agent can read a row mid-call - an order, an appointment, an account - and, when you allow it, write a single row back. The caller asks a question; the agent looks up the answer in your data and says it out loud.
The difference from every other approach is where the work goes. On a general developer platform, "let the agent read my database" means building and hosting a tool server: an endpoint the model calls, its own auth, its own deployment, its own on-call. Flowyte replaces that with a form. You point it at your database, choose the queries you want, and the platform freezes each one into a Skill the agent can call. No middleware to run, no server to keep alive.
Everything in the connector is also available through the public REST API, so a developer can automate the same connection in code - but nobody has to.
What can callers do when the agent reads your database?
The payoff is the moment a caller gets a real answer instead of "let me take a message." Because the agent reads from your live records, it handles the questions that used to need a person at a keyboard.
| Caller asks | What the agent does |
|---|---|
| "Where's my order?" | Looks up the order by phone number or order number and reads back the current status |
| "What's on my account?" | Reads the fields you mapped - a balance, a plan, a last visit - and none you didn't |
| "When's my appointment?" | Reads the appointment time and status and confirms it on the call |
| Greet by name | A lookup keyed on the caller's number lets the agent open with their name and their most recent record |
Best for: any call where the answer is a fact in your system, not a judgment call.
That last row is the one people remember. A read bound to the caller's phone number means the agent can open with "Hi Sam, calling about order 500?" instead of asking who's calling and why. It feels like the caller reached someone who already knows them - because the agent is reading the same record your staff would.
How do you connect a database to your AI phone agent?
Setup follows the connect a SQL database guide in the docs, one step at a time. You never hand the agent your admin login, and nothing goes live until you publish.
Create a least-privilege database user
Generate the setup SQL from the connector, then run it on your database as an admin. You get a read-only role by default; add a scoped write role only if the agent needs to change rows, and it reaches only the tables you name. The agent never uses your admin credentials.
Test the credentials before you store them
Run the built-in connection test first. It checks reachability, TLS, authentication, a read probe, a read-only-session proof, and a live-call latency verdict, then returns a single pass or fail - without saving anything.
Connect
Pass the same credentials to the connect step. They're encrypted at rest and never echoed back to you or the agent.
Discover the schema and scope it
Introspect the database into a browsable schema, then block any table or column the agent must never see. Blocked data disappears from the schema browser and is refused later when you bind a query.
Bind a query as a Skill
Map a read - or a scoped write - onto a Skill: pick the operation, connect the caller's input to the filter, and choose the columns to read back. Prefer to describe it? Give a plain-language goal and the AI assistant proposes the binding for you to review.
Publish and test
Binding edits your draft agent. Publish so live callers get real data, then try it in the simulator before a real call ever lands.
Flowyte refuses a database connection over an unencrypted channel - the SSL mode must be require, verify-ca, or verify-full, and a host that resolves to a private, loopback, or metadata address is refused too.
If you're new to Skills, the guide on building AI phone agent Skills walks through how a mapped query becomes something the agent can call on a live line.
Is it safe to give an AI agent access to your database?
Yes - because the safety is the architecture, not a promise. Four controls stack on top of each other, and each one is set by you, not the agent.
| Control | What it does |
|---|---|
| Least-privilege user | You connect a scoped user, never your admin login. Reads are read-only; writes reach only the tables you granted |
| Data scoping | Tables and columns you block never reach the schema browser, the AI assistant, or a binding |
| Frozen queries | Each Skill compiles to one parameterized statement. The agent passes parameters and can't run arbitrary SQL |
| Gated writes | A write is a single-row insert or update by unique key, never bulk, and stays disabled until you enable it |
Read those top to bottom and the guarantee is plain: nothing runs that you didn't author. The agent never sees raw SQL or the full schema. It never sees a column you scoped out - blocked fields like a card number or an identifier simply aren't in the data it works from. And it can't make a bulk change or run a query you didn't map, because there's no open SQL for it to write. Reads are the floor; writes are the exception you turn on deliberately, one shape at a time.
That's the part general platforms leave to you. When you build your own tool server, you own every one of these decisions and the code that enforces them. Here they're the default the connector ships with.
Who should connect a database - and when to use Google Sheets instead?
Connect a database when the answers your callers want already live in one. That covers stores with an orders table, service businesses running a jobs or appointments system, and any operation whose customer records sit in Postgres or MySQL. If a caller's question has a factual answer in a row you keep, the agent can give it.
Skip the database connector in one honest case: you don't have a database. If your bookings and customer notes live in a spreadsheet, connecting Postgres isn't the move - the Google Sheets Skill reads and logs to a sheet directly, no database required. The SQL connector supports Postgres and MySQL only; it isn't a path for spreadsheet data, and forcing your data into a database just to answer calls isn't worth it.
For teams with an engineering group, the whole flow is scriptable through the API tutorial - but the guided connection exists so you don't need one.
Video Transcript
Prefer to read? The full narration from the walkthrough video:
Walkthrough transcript
Callers don't ask generic questions. They ask about THEIR order, THEIR account, THEIR appointment — and those answers live in your database. In this guide: connecting an AI agent straight to your Postgres or MySQL in Flowyte — safely — and answering from your own data, live on the call.
Connecting is a form, not a project. Host, port, database, user, password — and SSL required, always. Fill it in once, for the database you already run. No code, no middleware, no sync jobs.
Before anything touches your data, Flowyte generates the database user for you — scoped to read-only, with a strong generated password. You run one script, on your side. The agent never gets admin credentials, because you never create any.
Hit discover, and Flowyte reads the shape of your database — the tables, the columns, the indexes, and how they join. Here's our store: customers, orders, and callbacks.
Then you decide what the agent may never see. Block a table, or block a single column — an email column, say — and it disappears from every picker and every binding. Scoping survives re-discovery, and it's enforced when skills are built.
So think of it as a wall between the agent and your data. Grant a read-only user, and reads are all that can ever exist. Your blocks filter what's visible. And the only things that cross are the fields you explicitly allowed.
Now the part every other platform makes you code: binding a lookup. Pick the table, pick one indexed column to filter on, and choose exactly which fields come back — even a joined field, like the customer's name on an order. It compiles to a frozen, parameterized statement. Nothing dynamic, nothing the model invents — it runs your query, or nothing at all.
And here's the whole round trip. The caller asks, the agent fills in one parameter, the frozen query crosses to your database — and one indexed read comes back. It's built this way for speed: no generated SQL, no table scans, no detours. One indexed read runs well under a second, even on million-row tables — fast enough to answer mid-conversation.
Live, against the real database: the caller asks about order one-zero-zero-zero-four-two. One indexed read — and the agent answers from the row, with the customer's name pulled through the join. Shipped, four ninety-nine, under Sarah Chen. Your data, in the agent's voice, the moment the caller asks.
And every run is on the record. The live timeline shows the exact skill, the exact parameter, and what came back. If you ever wonder what the agent touched — it's written down.
Now let's go two-way. We bound a write — and look what happened the moment it was created: it landed disabled. Every new write waits for a human review before it can ever run.
Reviewed and enabled — now watch the gate work. The caller asks for a callback about their order. The agent reads it back, waits for an explicit yes — and only then writes exactly one row. There's the insert, on the record.
That's the write posture: single-row only, confirmed with the caller, and reviewed before it ever runs. Updates demand even more — a verified caller identity. And beneath it all, a database user scoped to exactly the grants you chose. Nothing more.
And everything you just watched works both ways. Click through it in the portal — or script it end to end through the public API: connect, discover, scope, and bind. Same operations, same guardrails, either way.
That's your database, connected: one form, one scoped user, frozen queries — and answers from your own data on every call. Start free at Flowyte dot com — and if you'd like a hand, we're always here: support at Flowyte dot com.
Common Questions
Which databases can I connect to my AI phone agent?
PostgreSQL and MySQL. You connect your own database with a scoped user you create, and the agent reads and optionally writes live records during calls. No other database types are supported through this connector.
Is it safe to give an AI agent access to my database?
Yes, because access is scoped at every layer. You connect a least-privilege user - never your admin login - so reads are read-only and writes reach only the tables you granted. You also block any sensitive table or column, and it never reaches the agent, the schema browser, or a query. Nothing runs that you did not author.
Can the agent update records, or only read them?
Reads are the default. The agent can also write, but a write is limited to a single-row insert or an update by unique key - never a bulk change - and it stays disabled until you review and enable it. You decide exactly which write, on which table, ever runs.
Do I need a developer to set this up?
No. The connection is a guided form: you run one piece of generated SQL to create the scoped user, then map queries in the interface. If you would rather describe the query than build it, give a plain-language goal and the AI assistant proposes the binding for you to review. A developer can automate the same steps through the API, but it is not required.
What if my data is not in a database?
If your records live in a spreadsheet, use the Google Sheets Skill instead - it reads and logs to a sheet directly with no database involved. The SQL connector is only for Postgres and MySQL, so it is not the right tool for spreadsheet data.
Can the agent see sensitive columns like card numbers?
Only if you let it. Data scoping lets you block specific tables and columns, and blocked fields vanish from the schema browser and are refused when you bind a query. A column you scope out is never part of the data the agent works from, so it cannot read it back or expose it on a call.
Put your data on every call
Connecting a database is the step that turns a capable agent into one that knows your customers. You create a scoped user, test and connect, block anything sensitive, and map the exact queries you want - and from then on the agent answers order status, account questions, and appointment lookups from your live records, safely, on every call. Reads by default, writes gated and off until you turn them on, nothing running that you didn't author. See current plans on the pricing page, then start building. Your first agent, and your first connection, are free to set up.
Connect Your Database to a Live Agent
Point Flowyte at your Postgres or MySQL database, map the queries you want, and let your agent answer from real data. Free credits at signup, no credit card required.
Start Building FreeAbout the Author
Flowyte Team
Product Team
The team behind Flowyte, the AI agent studio for phone and chat. We build the product, run it on our own phone lines, and write these guides from what we ship and test - not from theory.
