How two engineers from the Hungarian adesso team evaluated Text2SQL architectures for the AWS data platform of a German premium car manufacturer.
For several years, the Hungarian division of adesso has been part of the team that builds and operates a cloud data platform for a German premium car manufacturer. The platform follows a classic AWS setup: data is stored in S3, catalogued in AWS Glue, queried with Amazon Athena, and protected with Lake Formation permissions down to row and column level. Business analysts, the so-called power users, log in with per-group SSO roles and write their SQL in Athena.
This works well, but SQL is a real barrier for many colleagues on the business side. A question like “How many cars were sold in Hamburg last month?” is easy to say and much less easy to write as a correct query against a data model you do not know by heart. The wish from our users was clear: ask the platform questions in natural language and get reliable answers back, an approach usually called Text2SQL.
We already experimented with this two years ago, in the early days of LLMs. The results were promising, but everything had to be glued together with custom code, and the topic went back to the backlog. Then the Model Context Protocol (MCP) arrived and changed the picture.
A proof of concept in three weeks
To verify the technical side, two of our engineers ran a proof of concept over roughly three weeks, inspired by open-source projects such as the AWS Data Processing MCP server and the community Data Product MCP project. The setup was surprisingly small: a local MCP server connected to Athena, used from GitHub Copilot, with credentials coming from a normal AWS SSO login on the developer machine.
With this, the LLM could browse the Glue catalog, understand the schema, generate SQL, run it on Athena, and explain the results in plain language. Technical viability: verified. What surprised us was not that it worked, but how little effort it took compared to our attempt two years earlier. MCP removed exactly the integration code that had made the first experiment expensive. However, a PoC running on a developer laptop with developer credentials is far from something a business user can open in a browser.
The real question is not AI, it is authorization
Our client has strict and sensible rules: employees are not allowed to install arbitrary tools on their computers, so a managed solution in the browser is strongly preferred. At the same time, the platform already has fine-grained permissions per user and group, and any GenAI feature must respect them. We collected four requirements:
- Users can get answers from the data in natural language, with high confidence.
- Authorization stays fine-grained per user and group, exactly like the existing platform setup, including Lake Formation row-level and column-level permissions.
- Quick and simple diagrams can be generated, for example, a bar or a pie chart.
- Optionally, dashboards can be generated too.
With these requirements, we designed two architecture options on top of the existing platform and compared them with two commercial products.
Option A: Amazon Bedrock with Knowledge Bases
The first option stays completely inside the current setup. Users keep logging into their existing per-group SSO roles, and next to Athena they simply get a second entry point: Bedrock chat. For each group we pre-create a Bedrock Knowledge Base that points to the Glue databases the group is allowed to see, and Lake Formation enforces the permissions as usual.
Figure 1: Option A, Bedrock chat with per-group Knowledge Bases on top of the existing platform
This option is the cheapest and the fastest to set up, because it reuses the whole permission model. The downsides: the Bedrock chat frontend is intended more for testing than for end users, and it cannot render diagrams, so our third requirement is not fulfilled.
Option B: OpenWebUI, MCP and a small config Lambda
The second option brings the PoC idea to the browser. We host OpenWebUI, a popular open-source chat frontend, on ECS in AWS, with OIDC login. A small configuration Lambda pre-creates the OpenWebUI users and their MCP server configurations, including per-user IAM credentials stored in a secure way. When a user asks a question, the Athena MCP server runs the query with the credentials of that concrete user, so Lake Formation filtering works exactly like today.
Figure 2: Option B, OpenWebUI with per-user MCP servers, configured by a Lambda
From a security point of view this design has nice properties: every query executes with the actual user’s permissions (least privilege), the existing AWS SSO, Athena and Lake Formation infrastructure is reused without major changes, and there is a clear audit trail of who accessed which data and when. OpenWebUI can also render diagrams and is flexible thanks to its plugin system. The price of this flexibility is that we have to host one more component and write some glue code for the configuration. A sub-variant connects OpenWebUI to Bedrock Knowledge Bases instead of MCP, but this ties us strongly into the Bedrock ecosystem.
Options C and D: buying instead of building
For completeness, we also looked at commercial products. Amazon QuickSight with Amazon Q is what we internally called the “pay-to-win” solution: it works out of the box, generates not only diagrams but complete dashboards, and integrates natively with Lake Formation. The catch is the price – around 50 dollars per user per month. We also checked Tableau Online with Tableau Agent, but at the time of our evaluation, it could not query the data itself, so we dropped this option.
What the numbers say
For a realistic scenario of ten users, each running ten queries per day, we estimated the monthly costs:
| Option A (Bedrock only) | Option B (OpenWebUI + Bedrock) | Option C (QuickSight with Q) | |
| LLM usage | $72 | $72 | included in license |
| Infrastructure | $0 | ~$41 (Fargate Spot, 1 vCPU, 2 GB) | $0 |
| Licenses | $0 | $0 | $50 per user, $500 total |
| Total per month | $72 | $113 | $500 |
The LLM part is surprisingly cheap. A complex query consumes roughly 8,000 tokens, which is around 2 cents with Claude Sonnet on Bedrock. In other words, the AI is not the expensive part of this architecture; hosting and licenses are.
What we learned
First, MCP moved the difficulty. Two years ago, the challenge was connecting the LLM to the data, and it needed a lot of custom code. Today, that part is almost free, and the hard question is identity: how to carry the actual user’s permissions through the whole chain of frontend, LLM, and query engine.
Second, in an enterprise environment, the frontend decision is a security decision. The constraint that users cannot install anything locally excluded the comfortable developer setups immediately, and it shaped both architectures more than any AI consideration.
Third, agentic querying is cheap. Our estimates showed that for the price of one commercial license, you can serve a whole team with an open-source frontend and pay-per-token models. This changes the build-versus-buy discussion quite a lot.
What comes next
Together with our client, we decided to evaluate Options A, B, and C hands-on in the next program increment. We will share the results in a follow-up post.
The team behind this work is part of the Hungarian division’s data and cloud competence area, which supports the client’s platform end-to-end, from ingestion pipelines to BI and now GenAI. If you are thinking about natural language access to your own data, we are happy to exchange experiences.
