Querying Databases Safely with Natural Language: Architecture and Practice Guide

Why Let a Model Touch the Database Directly

Data analysis and troubleshooting take up a significant share of developer time. A simple ad-hoc query usually means confirming the table schema, writing multi-table joins, and then double-checking the results. For anyone unfamiliar with the business database, this process has a steep learning curve. Large language models can understand natural language and generate SQL. If a model can safely read schema information and execute queries, the gap between “describe what I need” and “get the result” shrinks dramatically.

This approach fits three main scenarios:

• Ad-hoc data analysis: quickly checking key metrics, such as order volume over the last 7 days or the distribution of average order value.
• Troubleshooting: when you can’t remember the schema, the model reads the metadata first, then assembles cross-table joins.
• Development assistance: giving the model knowledge of table relationships so it generates queries and data validation scripts that match the actual structure.

Model-generated queries are not always correct. The model may misinterpret a field’s meaning, miss a filter condition, or trigger a full table scan on a large table. So when evaluating such a solution, look at three things: whether the connection is stable, whether query results are accurate, and whether the operation could accidentally damage data.

Overall Architecture

A workable natural-language querying solution typically has four layers:

1. Interaction layer: a client application that supports a standard tool-integration protocol, responsible for receiving user questions and displaying results.
2. Protocol layer: wraps database capabilities as tools the model can call, such as listing tables, viewing schemas, and executing read-only queries.
3. Access gateway: handles connection management, SQL validation, result truncation, and audit logging.
4. Data layer: the actual storage—relational databases, key-value stores, and so on.

The benefit of layering is clear boundaries of responsibility. Clients can be swapped out, database drivers upgraded independently, and security policies implemented uniformly in the gateway rather than scattered across every client’s configuration.

The call flow can be summarized as:

User question → Client → Tool calls (list tables / view schema / run query)
             → Access gateway (permission check, SQL filtering, row limits, audit)
             → Database (read-only account)

Core Capabilities in Detail

3.1 From Natural Language to Query

For the model to write reliable SQL, it needs three kinds of information: what tables and fields mean, how tables relate to each other, and the business definitions behind the metrics. For example, does “spend amount” exclude refunds? Does “order count” include cancelled orders? Field names alone can’t answer these questions.

In practice, you can put this information into database column comments, or maintain a standalone data dictionary. Business definitions should be written out explicitly—never let the model guess. The clearer the definitions, the more consistent the generated queries.

3.2 Understanding the Schema

The first step in schema understanding is reading metadata. Relational databases usually provide an information schema or equivalent views where you can query table names, column names, data types, primary keys, and indexes.

A recommended implementation is two-step: first return lightweight information such as table names and brief descriptions; once the model has identified the target tables, expand the full column details. This avoids stuffing the complete structure of hundreds of tables into the context at once, saving space and reducing the chance that the model gets distracted by irrelevant information.

Here is a standard SQL–style example, for illustration only:

SELECT table_name, column_name, data_type, is_nullable
FROM information_schema.columns
WHERE table_schema = 'shop'
ORDER BY table_name, ordinal_position;

Different databases name and scope their system views differently, so adjust according to the engine you use.

3.3 Managing Multiple Databases

A single client often needs access to several databases—a production read-only replica, a test database, a reporting database. Assign each connection a unique alias, and have the model pass the alias explicitly when calling tools, so queries never go to the wrong environment.

Keep connection parameters in environment variables or a secrets management service, never in plain text in config files that might get synced or shared. Alias names should also reflect environment and purpose—such as prod_readonly and test_main—making them easy to identify in audit logs.

3.4 Read-Only First

Read-only access is the most important security boundary. Enforce it at three levels simultaneously:

• Account level: use a database account with only query privileges. This is the most reliable layer—even if upper-level validation fails, the account cannot modify data.
• Session level: set the connection to read-only transaction mode, rejecting accidental writes.
• Statement level: parse SQL in the gateway and allow only query-type statements, rejecting DDL, DML, permission changes, and multi-statement concatenation.

Statement-level filtering is only a supplementary measure. SQL dialects vary widely, and string parsing can’t cover every syntax, so it cannot replace account permissions. The following code only demonstrates the idea of coarse-grained checks; production systems should use a mature SQL parser:

ALLOWED_PREFIXES = ("select", "show", "describe", "explain", "with")
FORBIDDEN_KEYWORDS = {"insert", "update", "delete", "drop",
                      "alter", "truncate", "grant", "revoke"}
def is_read_only(sql: str) -> bool:
    normalized = sql.strip().lower().rstrip(";")
    if ";" in normalized:          # Reject multi-statement concatenation
        return False
    if not normalized.startswith(ALLOWED_PREFIXES):
        return False
    tokens = set(normalized.replace("(", " ").replace(")", " ").split())
    return not (tokens & FORBIDDEN_KEYWORDS)

This code cannot detect keywords inside string literals and does not handle comments or similar constructs, so treat it as a first-pass filter only.

3.5 Protecting Results

Query results need boundaries. Returning an entire table at once can overflow the model’s context and may leak sensitive data. Common practices include:

• Automatically appending a row limit; when exceeded, prompt the user to narrow the query scope, for example by adding a time filter.
• Setting query timeouts so slow queries don’t hold connections indefinitely.
• Masking sensitive fields such as phone numbers and ID numbers in displayed results.
• Preferring aggregate queries for reporting needs to reduce the volume of raw detail rows returned.

In reporting scenarios, the model usually only needs summary numbers. Having the database perform the aggregation is faster—and safer—than pulling raw details back to the client and computing there.

3.6 Auditing and Traceability

Every tool call should be logged with the call time, client identifier, database alias, SQL text, execution duration, and number of rows returned. Audit logs serve two purposes: investigating suspicious queries after the fact, and reviewing whether the model-generated statements were reasonable.

Logs must never contain plaintext passwords or full sensitive data. For queries involving personal information, record only the field names and row counts, not the actual values.

A Complete Workflow

Take “count orders from the last 7 days” as an example. A typical interaction looks like this:

1. The model calls the table-listing tool to find order-related tables.
2. The model calls the schema tool to confirm the timestamp and order status fields.
3. The model generates an aggregate query, stating in the definition whether cancelled orders are excluded.
4. The gateway validates and executes the query, returning results grouped by date.
5. The model presents the conclusion in natural language, along with the scope of the statistics.

An example query:

-- Time boundary syntax depends on the specific database dialect; illustrative only
SELECT DATE(created_at) AS order_date,
       COUNT(*)         AS order_count
FROM orders
WHERE created_at >= :start_date        -- Start date passed in as a parameter
  AND status <> 'cancelled'            -- Exclude cancelled orders; confirm the definition with the business
GROUP BY DATE(created_at)
ORDER BY order_date;

Using parameter placeholders instead of string concatenation avoids injection risks and makes audit logs easier to process uniformly.

Common Pitfalls and Caveats

• Model conclusions need verification.