AI Chatbot Database Integration

Two Different Jobs People Call Database Integration

Clients who ask us to hook a chatbot up to their database usually mean one of two things, and each needs a different architecture.

Structured lookups. The answer is a specific row or a small set of rows: order 48213 shipped Tuesday, the three-quarter-inch fitting shows 14 units at the north warehouse, Thursday has openings at 9:00 and 1:30. That data changes constantly and must be exact. The assistant needs live access to the system of record, scoped tightly to whoever is asking.

Knowledge retrieval. The answer is buried in text: product manuals, policies, past support tickets, service descriptions. The usual approach there is retrieval-augmented generation, in which documents are split into chunks, converted into vector embeddings and stored in a vector index. That index may itself sit in your database, for example PostgreSQL with the pgvector extension, but the challenge is search relevance rather than permissions on live transactional records. Our chatbot knowledge base setup page deals with that side.

Plenty of projects need both. The rest of this page is about the first job: letting an assistant query operational data and, with care, write to it.

The Model Never Writes SQL Against Production

Large language models can generate SQL, and it is tempting to hand one a connection string and a schema. For a customer-facing chatbot that is a serious mistake. A visitor can phrase a question, or hide an instruction inside pasted text, that nudges the model to query another customer’s orders, dump a whole table, or run something heavy enough to slow your application. Instructions in a system prompt asking the model to behave are not a security boundary.

Instead we build a small set of functions, usually called tools, that the model may call by name with typed arguments. Each tool is ordinary server code wrapping a fixed, parameterized query. A typical order-status assistant might have exactly three:

The model chooses which tool fits the question and words the reply. Your code determines what data exists for this person. Because the query text is fixed and arguments are bound as parameters, SQL injection through the conversation has no path in, and because customer identity comes from the authenticated session rather than from anything typed into the chat, the bot cannot be talked into looking up someone else. The same function-calling pattern underpins the broader AI agents we build to take actions inside business systems.

Permissions Belong in the Database, Too

The tool layer is the first boundary. The database should enforce a second, so that a bug in our code or yours cannot widen access.

• A dedicated database role for the chatbot service, separate from your application’s main user, with SELECT granted only on the tables or views the tools use.
• Views instead of tables wherever practical. A view exposing order number, status and ship date is far safer to grant than the full orders table with its payment and address columns.
• Row-level security where the engine supports it, as PostgreSQL does. A policy restricts every query from the chatbot role to rows matching the customer ID set for the session, so even a flawed query returns only that customer’s rows.
• A read replica for read-heavy assistants, so a burst of chat traffic cannot slow the primary database your staff and checkout depend on. Where replica lag matters, answers say so (“status as of a minute ago”).
• Statement timeouts set on the role, such as PostgreSQL’s statement_timeout or the equivalent setting on MySQL or SQL Server, so a runaway query is stopped by the database rather than by luck.
• Network isolation. The database is never opened to the public internet for the chatbot’s sake. The chatbot backend reaches it over a private network, VPN or tightly allow-listed connection.

Tracing a Single Order-Status Question End to End

Here is what happens, step by step, when a signed-in customer types “has my patio set shipped yet?” into an assistant built this way.

1. The website passes the chat backend a session token from its existing login. The backend resolves it to customer 7731; the model never sees or chooses that ID.
2. The model reads the question and decides to call list_recent_orders, because no order number was given.
3. The backend runs a fixed query as the chatbot role, with the session’s customer ID set so the row-level policy applies. Three orders come back.
4. Only order number, date and a short item description go to the model. It spots the patio set and calls get_order_status with that order number.
5. The status query returns shipped, the carrier and an estimated delivery date. The call, its arguments and a row count are written to the audit log.
6. The model answers in one or two sentences and offers the tracking link your system already generates.

If the same question arrives from a visitor who is not signed in, step one fails closed: the bot asks for the order number plus the email used at checkout, and a verification code goes to that email before anything is looked up.

Where Text-to-SQL Is Acceptable

Free-form natural-language querying does have a place: internal reporting. A sales manager asking “what were our top ten service types by revenue last quarter, split by region?” gets genuine value from a model that writes the SQL. We build that kind of assistant only behind your staff login, and with guardrails that assume the generated query will sometimes be wrong:

1. It connects with a read-only role on a replica or reporting database, never the primary.
2. Generated statements are parsed, and anything other than a single SELECT is rejected before it runs.
3. Only an allow-listed set of reporting views is visible, with sensitive columns removed.
4. Timeouts and result caps are enforced by the database itself.
5. The SQL is displayed beside the answer, so a person can sanity-check the logic before acting on the number.

That last point matters more than it looks. A text-to-SQL model can produce a confident, neatly formatted figure from a query that joined the wrong tables or double-counted refunds. Showing the query turns a hidden error into a visible one.

Letting the Chatbot Write: Bookings, Tickets and Service Requests

Some assistants have to create records: a service request, a booking, a support ticket, a row in a custom database your team built. Writes get stricter treatment than reads.

Every write passes through an application endpoint or stored procedure that validates the payload the way your own software would. Required fields, types, allowed status values and foreign keys are checked in code. The model supplies arguments; it does not pick the table or the columns. Inserts that span more than one table run inside a transaction, so a failure halfway leaves nothing half-written. Each request carries an idempotency key derived from the conversation, so a retry after a network hiccup cannot book the same visitor twice.

Updates and deletes are rarely given to a public bot at all. Cancelling an appointment, for instance, is better handled by a signed link emailed to the customer than by a chat instruction the model has to interpret. When a write carries financial or irreversible consequences, the chatbot prepares it and a staff member confirms it.

Latency, Indexes and How Much Data Reaches the Model

A chat turn that waits on a slow query feels broken to the visitor. Much of the database work in these projects is plain performance tuning:

• Each tool query is checked with the database’s query planner, and indexes are added for the lookups the bot actually performs, typically order number, customer ID and SKU.
• The chatbot backend uses a connection pool instead of opening a connection per message. Serverless deployments in particular can exhaust a database’s connection limit quickly without one.
• Slow-changing data, such as service areas, business hours or product categories, is cached for minutes rather than queried on every message.
• Tools return compact, labeled results, not raw rows. Every value sent to the model costs tokens and adds delay, and passing forty columns when the answer needs three also raises the odds the model repeats something it should not.

Audit Logs and Privacy Controls

Once a chatbot can reach customer records, you need to be able to answer who saw what, and when. Each tool call is logged with the session, the verified customer identity if there is one, the tool name, its arguments and the number of rows returned, but not the personal data that came back. That log can settle a customer complaint or support a security review without becoming a second copy of your database.

What the model provider sees matters as well. Tool results travel to the model so it can phrase an answer, so we check the provider’s data-retention and training terms for the account in use, return the minimum fields required, and mask values the model never needs to repeat, such as full street addresses or partial payment details. For regulated data like health records, the right answer may be that a particular table is never reachable from a chatbot at all, and we will say so when that is the case.

Questions We Ask Before Quoting

Database integrations vary more than almost any other chatbot work, so the free consultation is mostly questions:

• Which database engine and version, and who hosts it: your own server, a cloud provider, or a software vendor?
• Is there an existing application API we should call instead of touching tables directly? If one exists it usually already enforces your business rules and is often the better integration point; our chatbot API integration page covers that route.
• How are customers identified today, and can the assistant reuse that login or send a verification code?
• Which questions do customers or staff actually ask? We want a real list, ideally pulled from support email or call notes.
• Is there a staging copy of the database with realistic but anonymized data?
• Who approves schema changes, and may we add a role, views and indexes?

If the database belongs to a packaged product you do not control, direct access may breach its license terms or simply be unsupported, and we will look for an export, report or official API instead.

How EVOTECH Delivers a Database-Connected Chatbot

1. Map questions to tools. The real question list becomes the smallest set of tools that answers it, each with its query, arguments and output fields written down.
2. Prepare the database. With your approval we create the role, views, row-level policies and any indexes, scripted as migrations you can review and roll back.
3. Build against staging. Tools are developed and tested on anonymized data, including adversarial prompts that try to reach other customers’ records.
4. Connect the assistant. The model receives the tool definitions and instructions on when to use each one, with verification required before any personal lookup.
5. Load and outage tests. We simulate traffic spikes and a database that stops responding; in the latter case the bot says it cannot check right now and offers a phone number or a way to be contacted.
6. Launch and handover. You receive the tool catalogue, the migrations, the log format and a runbook, so your developers or ours can extend it later.

This is custom software engineering as much as AI work, and we treat it that way: version-controlled, reviewed and documented. EVOTECH IT LLC, a US-based team with more than two decades in business, handles it remotely for organizations nationwide; call (832) 359-2425 to set up a no-cost scoping conversation.

Related services

Frequently asked questions