Natural-language data queries lower the barrier to starting a query; they do not remove the need to verify retrieval logic. Whenever a number will enter a weekly meeting, financial report, or product decision, SQL remains shared evidence for reviewing grain, joins, filters, denominators, and time boundaries.
Natural Language Expresses Intent; SQL Fixes the Logic
“Show retention among high-value new customers last quarter” sounds natural to a person but is not a complete database specification. Does high value mean first-order amount, cumulative revenue, or gross margin? Is a new customer defined by registration or first payment? Does retention mean a return visit, activity, or another purchase? Is last quarter a calendar or company fiscal quarter?
Text-to-SQL can turn this request into a draft query, but that translation necessarily makes choices. Visible SQL lets the team discuss those choices concretely:
WITH new_customers AS (
SELECT customer_id, MIN(paid_at) AS first_paid_at
FROM orders
WHERE status = 'paid'
GROUP BY customer_id
)
SELECT ...
This code establishes at least one definition: a new customer is identified by their first paid order. If only the natural-language request and final number remain, that choice can easily disappear inside execution.
| Layer | Best suited to carry | Should not carry alone |
|---|---|---|
| Natural language | Goals, context, exceptions, decision needs | Precise row-level retrieval evidence |
| SQL | Grain, joins, filters, aggregation, time windows | Business priorities and causal interpretation |
| Human review | Definition tradeoffs, risk, whether conclusions are usable | Writing every boilerplate query from scratch |
This is not a contest between natural language and SQL. Each representation should do what it does best.
Enterprise Text-to-SQL Is Difficult Because of Context, Not Just Syntax
Early benchmarks often reduced the task to generating SQL from a question and schema. Spider 2.0 instead contains 632 workflow questions derived from enterprise data settings, often involving more than a thousand columns, multiple SQL dialects, metadata, documentation, and project code. In the latest paper revision, its o1-preview code-agent framework solved 21.3%, far below the 91.2% it reports for Spider 1.0. These numbers should not be extrapolated to every model, but they clearly show how sharply difficulty rises when a benchmark resembles a real environment. See the Spider 2.0 paper.
EntSQL in 2026 goes further by including private enterprise knowledge. Its 1,066 aligned Chinese and English examples cover five business domains, and most questions require internal metrics, reporting conventions, or organizational rules. The best evaluated system reached 15.9% on English input with long documents. Again, this is not market-wide accuracy; it is a reminder that sharing a schema does not tell a model how your company defines a “valid order.” See the EntSQL paper.
Teams adopting natural-language queries therefore need:
- Searchable schemas and column descriptions.
- Business definitions for metrics, status codes, fiscal quarters, and similar concepts.
- The query dialect and permitted data sources.
- A visible SQL path that people can inspect, test, and revise.
Review AI-Generated SQL for More Than Whether It Runs
Successful execution proves only that the syntax and object names are broadly valid. Before formal use, apply the five-point “GJFAT” check:
- G — Grain: Does one final row represent a person, order, event, or day?
- J — Join: Are keys unique? Does a one-to-many relationship cause fan-out?
- F — Filter: Are cancellations, test accounts, NULLs, and status values handled?
- A — Aggregation: Do
COUNT(*),COUNT(DISTINCT ...), and the denominator match the definition? - T — Time: Are time zone, inclusive boundaries, cutoff, and cohort window explicit?
Then add a minimal test query comparing row counts and distinct keys before and after joins. Product managers need not rewrite the SQL to move from “it seems to run” to “we know which question it answers.”
Lantide Data's SQL-First Division of Work
Lantide Data makes natural language an entry point without hiding SQL. The agent can explore schemas and draft Plans and SQL. In formal Project Analysis, the user reviews the Plan and then executes it; SQL tabs retain retrieval logic, while the Report carries conclusions and limitations. See SQL-first: keep definitions in tabs and the unified query layer.
People and agents share a DuckDB query pipeline in Lantide. Persistent SQL tabs can create local caches for downstream references, and Source Run can recompute upstream dependencies. This suits ad hoc exploration, collaborative definition work, and evidence that can be rerun. Lantide is not a replacement for nightly ETL, a shared warehouse, or a fixed dashboard; persistent operational workloads still belong on the appropriate platforms.
Conclusion
We still need SQL in 2026 not because everyone must become a SQL expert, but because formal numbers need a precise, executable evidence format whose differences can be compared. The practical future is not natural language replacing SQL. It is natural language expressing intent, AI drafting the query, SQL retaining the evidence, and people reviewing the definitions.