Ask your database: building a safe natural-language analyst

A natural language database query tool is easy to demo and hard to make safe. The demo connects a model to a schema and answers "how many orders last week?". The production version has to answer that for a regional manager who may only see her region, refuse a query that would scan a year of events, never run a write, and show the analyst exactly what it did when the number looks odd. This article walks through the six controls that make an NL analyst safe, how they fit together, and what building one involves.

What a natural-language analyst is and why safety comes first

The tool takes a question in English (or Hindi, or whatever your team uses), turns it into a query, runs it, and returns a table, a chart or a sentence. "Chat with your database" is the marketing phrase; "a junior analyst with database credentials and no supervisor" is the security description. Every control below exists because a language model will, sooner or later, produce a query that is syntactically valid, semantically wrong and operationally expensive. The natural-language data querying practice at Eazyware treats these controls as the product, and the model as a replaceable component behind them.

The six controls

Read-only by construction, not by prompt

The database user the tool connects as has SELECT on the views it needs and nothing else. Not "the prompt says do not modify data"; a role grant. On Postgres this is a role with default privileges revoked and specific grants added; the PostgreSQL documentation on privileges is the reference. On a warehouse it is a reader role with a resource monitor. If a prompt injection in a customer note persuades the model to emit a DELETE, the database refuses it, and the attempt is logged.

Row-level security tied to the person asking

The tool knows who is asking because the user signed in. That identity must reach the database, either through native row-level security policies that read a session variable, or through filters the compiler injects into every query from a role-to-filter map. What must not happen is the model being told "this user is in the West region; only show West data" and trusted to comply. The details, including negative testing, are in row-level security for AI analytics.

A semantic layer so the model selects, not invents

Accuracy problems in NL2SQL are mostly definition problems. If the model has to guess which of three date columns means "ordered" and which join gives revenue without double counting, it will guess differently on Tuesday than on Monday. A semantic layer defines metrics, dimensions, joins and time once; the model produces a structured request (metric, dimensions, filters, grain) and a compiler emits the SQL. We cover the build in the semantic layer: why text-to-SQL needs one. The short version: it turns a generation problem into a selection problem, and selection is far easier to evaluate.

Validate the query before it runs

Even compiled SQL is checked before execution. Parse it and reject anything that is not a single SELECT. Run EXPLAIN and reject plans with estimated rows above a threshold or without a filter on a partitioned table. Enforce a row limit, a statement timeout and, on a cloud warehouse, a per-user daily credit cap. When a query is rejected, the user gets a reason ("this would scan all events; add a date range") and the model gets a chance to revise. This is cheap engineering and it is what keeps the finance team from receiving a surprise warehouse bill in month two.

Show the SQL and the reading

Every answer carries three things: the result, the plain-English reading of the request the tool understood ("count of orders, status = delivered, last 7 days, by region"), and the SQL. Most users never open the SQL; analysts always do, and their trust depends on being able to. The reading catches the commonest failure, which is the tool understanding a different question from the one asked. A user who sees "last 7 days" when she meant "last week" corrects it in one message.

Say "I cannot answer that"

When the question needs a metric the layer does not define, or data the user may not see, the tool says so and offers the nearest thing it can do. Improvising is how trust is lost. Unanswerable questions are logged and reviewed weekly; they are the roadmap for the semantic layer.

Measure accuracy with a golden set

Collect one to three hundred real questions from Slack threads, ticket queues and analyst inboxes, with answers an analyst has verified. Run the tool against them on every prompt, model or schema change and track exact-match on the result, not on the SQL text. Break the number down by question type: simple aggregates, time comparisons, multi-entity joins, ranking. The overall figure is a headline; the breakdown tells you what to fix. Golden question sets describes how to build one; text-to-SQL accuracy explains why the headline number misleads.

A worked example

A last-mile logistics operator wanted regional managers to ask questions about deliveries, delays and driver utilisation without waiting for the data team. The data lived in the dispatch platform's Postgres database, the same platform described in the dispatch platform case study. The first build connected a reader role to a set of reporting views, defined a dozen metrics (deliveries, on-time rate, attempts per delivery, utilisation) in a reviewed YAML layer, and mapped the manager's region from the identity provider into a row filter injected into every query. Query validation rejected anything without a date range. Shadow mode ran for two weeks with the data team checking every answer against their own numbers; the disagreements were all definition disputes (what counts as a failed attempt), which were settled in the layer. The tool launched in the operator's chat tool, with SQL shown on request, and the data team's ad-hoc queue changed shape: fewer "how many" questions, more "why" questions, which is where they add value.

Team and timeline

A safe NL analyst is an AI engineer, an analytics engineer and a data owner on your side over four to eight weeks depending on how many metrics and roles the first release covers. Weeks one and two: reader role, golden set, first metrics and the role-to-filter map. Weeks three to five: compiler, validation, model integration and the chat or web surface. Final weeks: shadow mode beside the analysts, negative-case tests for access, tuning against the golden set. Pricing for natural-language data querying starts at $12,500 or ₹8L; a three-week ProofRun ($6,250–10,500) produces the accuracy number on your own data first. The pricing page lists the programs and Care Plans for ongoing metric changes.

Before you start: a checklist

• Create a read-only database role and reporting views; never reuse an application credential
• Map roles to row filters and column restrictions, and get security to sign it off
• Collect 100–300 real questions with analyst-verified answers
• Define the first twenty metrics and their owners in a semantic layer
• Set row limits, timeouts and a warehouse spend cap per user
• Decide where the tool lives: Slack, Teams, the web app, or all three
• Write the negative-case tests: queries that must be refused
• Name the data owner for the weekly review of unanswerable and wrong questions

Glossary

• NL2SQL / text-to-SQL: generating a database query from a natural-language question
• Row-level security: restricting which rows a user can read, enforced by the data layer
• Semantic layer: governed definitions of metrics, dimensions and joins that the model selects from
• EXPLAIN: the database's estimated query plan, used to reject expensive queries before they run
• Golden question set: real questions with verified answers used as the accuracy benchmark
• Shadow mode: the tool answers alongside humans, and the answers are compared before launch

Questions clients ask

• Should it query the production database directly? Prefer a read replica or reporting views. A replica isolates load; views hide columns nobody should see.
• Which model do you use? We route per task: a fast model for simple aggregates, a stronger one for multi-step questions, and open-weight models inside your VPC where data cannot leave.
• What happens when the schema changes? The golden set fails, which is the point. The semantic layer is updated and the set rerun before anything reaches users.
• Can users ask follow-up questions? Yes. Conversation state carries the previous request, so "now by month" modifies it rather than starting over.
• How do we stop prompt injection through data? The model never gets write access and its output is validated as a structured request, so text in a customer record cannot become a command.

Related reading

See conversational analytics in Slack and Teams for the delivery surface, natural-language reporting for turning answers into dashboards, and the data and analytics applications service for the reporting views underneath.

Build the controls first and the model second, and "ask your database" becomes a tool your security team can approve and your analysts will actually trust.