Text-to-SQL vs Natural-Language Analytics

Ask a table "what was revenue last quarter?" and two kinds of tool will answer. One returns a SQL query and leaves the running to you. The other returns a number or a chart and keeps the query out of sight. The difference decides how much of the checking is yours.

What the category is

Questions-to-data tools turn a plain-language question into something runnable against a database. They split into two kinds. Text-to-SQL returns a query. Natural-language analytics returns an answer, a number or a chart, and chooses the tables, joins and metric meaning itself.

What the official descriptions promise

Text2SQL.ai is the first kind. Its page describes questions answered as SQL on a schema you add, with an Insights view that shows the query, the results, a chart and an explanation together. Its desktop app can connect to a database, and the page says only schema names are sent to AI providers (as of October 2026, per the product's own page). The reader sees the SQL and can edit it.

AI-Surge Cloud sits nearby in the catalog: a no-code data-lakehouse and business-intelligence platform for building dashboards without pipeline code, with enterprise pricing on request. It is a platform around the data, not a query writer.

What the landing pages leave out

Databricks, which sells the second kind, describes the weak point in its own blog post. In a SQL workflow an analyst picks tables, joins and metric definitions. In a natural-language workflow the AI agent makes those same choices. The post's examples are plain ones: an approved calculation for "net revenue", a certified finance table instead of a marketing summary, a fiscal year that starts outside January, free-trial users left out of retention numbers (Databricks).

The same post argues the fix is governed data plus metric definitions the model can read, and answers that can be traced back to their sources. That is a vendor's position in a blog post, with no benchmark attached. But the failure it describes is easy to reproduce on any table: "revenue" can mean the sum of an amount column, the same sum minus refunds, or only paid orders.

One table, one question

Take a table orders(order_id, region, amount, status, created_at) and the question "revenue by region last quarter". A text-to-SQL tool might return:

SELECT region, SUM(amount) AS revenue
FROM orders
WHERE created_at >= date_trunc('quarter', now()) - interval '3 months'
  AND created_at <  date_trunc('quarter', now())
GROUP BY region;

Readable, and wrong in a way that shows: nothing filters status, so cancelled and refunded orders are counted. A reader who sees the query can spot that in a minute. A reader who sees only a bar chart cannot.

Checking a generated query before it runs

1. Read the filters first. Status, date range, test accounts. In the example above the error sits in the WHERE, where the status filter is missing, not in the SELECT.
2. Run EXPLAIN on it. In PostgreSQL, plain EXPLAIN shows the plan the planner generates without running the statement. EXPLAIN ANALYZE is different: the docs say it causes the statement to be actually executed, so side effects happen (PostgreSQL documentation). For anything that writes, wrap it in BEGIN; ... ROLLBACK;, or better, let the tool use a read-only role.
3. Compare to a number you already know. One region, one month, from a report someone trusts.
4. Ask for the same thing twice. Different results for the same question point at a missing definition.

Which one fits

Text-to-SQL fits people who can read SQL and want a draft faster than typing: analysts, developers, anyone who will review the query. The risk stays visible.

Natural-language analytics fits shared dashboards, but only where the organization has already written down what its metrics mean. Without that, it gives confident answers to ambiguous questions. A small team with one database and no metric definitions is better served by the first kind plus the four checks above.