AWS demonstrates Text-to-SQL on Amazon Bedrock for translating business questions into SQL

AWS published a detailed breakdown of a Text-to-SQL solution on Amazon Bedrock, which translates business questions in natural language into SQL queries and immediately returns the answer in an understandable form. This is not a separate new product, but a practical architecture for companies that have data but still lack quick answers to business questions.

Why BI Falls Short

AWS explains the problem simply: even in companies with strong analytics, users still hit a bottleneck of waiting for analysts or face limitations of pre-built dashboards. If a question goes beyond a pre-assembled report, you need joins, time slices, calculated metrics, and knowledge of the internal logic of tables. For sales, finance, or operations, this means losing hours or sometimes days on a one-off query that doesn't justify separate development by itself.

According to AWS, this is where standard self-service BI starts to struggle. Natural language in BI interfaces works well with pre-prepared semantic layers, but struggles with raw tables, internal terminology, and metrics that are calculated differently in each company. That's why AWS proposes building not just a SQL generator, but a system that understands business context: what revenue is, how pipeline is calculated, and which tables can even be joined together.

How the Pipeline Works

At the core of the architecture is Amazon Bedrock as the inference and orchestration layer, plus a knowledge graph for business context and an analytical warehouse for query execution. The AgentCore Runtime plays a central role: it takes the question, decides whether it needs to be broken down into subtasks, calls context search, triggers SQL generation, and returns the final answer. For companies, this is important because the logic is not hardcoded in a single prompt: it can be broken down into separate steps and controlled at each stage.

• classification of the question as simple or complex
• search for business context through GraphRAG
• SQL generation in structured format
• deterministic validation of the query before execution
• synthesis of the answer in natural language based on query results

For context, AWS uses a combination of Amazon Neptune and OpenSearch: the graph stores relationships between tables, columns, metrics, terms, and hierarchies within the company. Next, the system performs vector search across descriptions and values, traverses graph relationships, and provides the model only with relevant tables, fields, join paths, and business rules. For complex questions, the architecture can run multiple agents in parallel and select the most reliable result by majority voting.

Production and Control

The most practical part of the post is not about LLM, but about protective layers. AWS specifically emphasizes that prompts alone cannot reliably catch semantically incorrect SQL: a query can be syntactically valid but deliver a dangerous or simply false result. Therefore, after SQL generation, it is checked with deterministic validators at the AST level.

If the system detects a risk—for example, too broad a scan, incorrect aggregation, or missing necessary filters—it automatically corrects the query and tries again. The second topic is latency and access. According to AWS data, simple SQL queries in such a scheme are typically generated in about 3–5 seconds, although the total time depends on the model, the size of the knowledge graph, and the speed of the warehouse.

To maintain interactivity, AWS recommends parallelizing subtasks, saving tokens, and not inflating the agent context. In parallel, the architecture immediately includes Row-Level Security filters so that users see only the rows they already have access to according to corporate rules.

What This Means

AWS effectively shows that Text-to-SQL ceases to be a sandbox demonstration and becomes an engineering pattern for real BI scenarios. The main takeaway is not that LLM can write SQL, but that a working system requires a knowledge graph, checks, orchestration, and access control. For teams that want to give the business a chat interface to data, this is a good reference point: less magic, more infrastructure and rules.