How to Let Users Chat With Your Database

Chatting with a database means turning questions into safe, read-only SQL

Letting users chat with your database means translating their plain-English question into a SQL query, running it safely, and returning the answer — a pattern called text-to-SQL. A language model reads the user's question along with your schema, writes the query, and your system executes it against a read-only connection. Done carefully, it lets non-technical users ask "how many orders shipped last month" and get a real number from live data. Done carelessly, it is a security incident waiting to happen, so the guardrails matter every bit as much as the model.

This guide covers both halves: getting accurate SQL out of the model, and making sure that SQL can never do harm no matter what a user types. The safety half is not optional polish — it is the foundation, because a model that occasionally writes the wrong query is acceptable while a model that can delete data is not.

Step 1: Ground the model in your schema

A model cannot write correct SQL for tables it has never seen, so context is everything. Provide the relevant schema — table names, columns, types, and relationships — so it writes queries that actually match your database rather than a plausible guess at one.

• Supply table and column definitions, ideally with a short description of what each represents in business terms.
• For large schemas, retrieve only the tables relevant to the question rather than dumping the entire catalogue into the prompt.
• Include a few example question-and-query pairs so the model learns your naming conventions and joins.

Step 2: Enforce read-only, least-privilege access

This is the non-negotiable safety layer, and it is enforced by the database, not by hoping the model behaves. The connection the generated SQL runs on must be incapable of changing data, full stop, so that even a perfectly worded malicious question is harmless.

Give the chatbot a database user with read-only permissions on only the tables it needs. Even a crafted malicious question then cannot delete, update, or escalate privileges.

• Create a dedicated read-only role; never reuse an application or admin connection for this.
• Restrict it to specific tables or views, not the whole database, following least privilege.
• Expose curated views rather than raw tables when sensitive columns are involved.

Step 3: Validate before executing

Never run generated SQL blindly, because the model can misread an ambiguous question or, in rare cases, be steered by injected text in the input. Parse and check the query first — confirm it is a single read statement, reject anything that writes or touches tables outside the allowlist, and enforce a row limit so a careless query cannot return millions of rows and overwhelm your interface.

• Allow only SELECT statements; block writes, schema changes, and multiple statements in one query.
• Add a LIMIT automatically so results stay bounded even when the user did not ask for one.
• Set a query timeout so an expensive query cannot hammer the database or block other users.

Step 4: Return answers people can trust

Show users not just the answer but how it was derived, because a number with no provenance is hard to trust and impossible to debug. Returning the generated SQL — or a plain-language summary of it — lets a knowledgeable user sanity-check the logic, and it surfaces the mistakes the model makes when it misreads an ambiguous question.

• Display the query alongside the result so the reasoning is auditable by anyone who cares to look.
• Format results as a clear table, and state plainly when a question was ambiguous and the model guessed.
• Log every question and generated query to find where the model consistently misunderstands.

Step 5: Handle the limits honestly

Text-to-SQL is powerful but not infallible. Complex joins, ambiguous wording, and business logic the schema does not capture all trip it up, and no amount of prompting makes it perfect. Keep humans in the loop for anything consequential, scope it to analytical read queries rather than operational changes, and be candid that it answers most questions well and a few questions wrong. That honesty is exactly why read-only access and visible SQL are mandatory rather than optional — they turn an occasional wrong answer from a hazard into a minor, visible, correctable event.

Prefer it built and managed for you?

BSH Technologies builds text-to-SQL and data-chat systems with schema grounding, strict read-only access, query validation, and auditable answers. If you want to let your team ask your data questions safely, talk to BSH Technologies or explore our AI & automation services.