Case Study: Querying SQL Databases in Plain English with AI
Many organizations store critical business data in SQL databases, but getting it out requires technical SQL knowledge. We built a tool that lets any employee ask in plain English.
Many organizations store critical business data in SQL databases, but accessing that data requires technical SQL knowledge. We worked with a client to build an AI-powered natural language querying system that allows any employee to retrieve information from enterprise databases using plain English questions.
The Business Problem
The Vancouver-based communications company relied heavily on enterprise SQL databases to store operational and financial data, but accessing that information required technical SQL knowledge. The organization was dependent on a single technical staff member to retrieve data and generate reports.
Whether leadership needed financial performance metrics or another department required operational insights, requests had to be manually submitted and processed by this one individual. This created several business challenges:
- Employees experienced delays in accessing critical information
- These delays compounded into issues for other business operations, meetings, and reporting
- The technical staff member became overloaded with repetitive manual SQL querying tasks
- Time spent pulling data reduced IT focus on other responsibilities
Although the company had access to large amounts of valuable business data, much of it was effectively locked behind SQL expertise. The organization needed a more scalable way for non-technical teams to access information directly and improve business intelligence workflows.
SQL query code example:
SELECT TOP 5 * FROM TRADES ORDER BY purchase_price DESC;
The AI Solution
To eliminate reporting bottlenecks and reduce dependency on manual SQL querying, we developed an AI-powered natural language interface that allows any employee to retrieve data from SQL databases using plain English.
The chat interface accepts a user's natural language query and, using the underlying database schema as context, a locally hosted LLM translates it into executable SQL. Once the data is retrieved from the database, results are presented clearly back to the user in the chat interface.
The system can format responses into tables and can retry queries that look incorrect on inspection. The interface also lets the user save and rerun queries at a later date.
A user could ask, "What is the total number of hours each technician worked this month?" and the system would write the query and return the result. If the user saved the query, it could be run every month to get fresh results.
Technical Implementation
A physical server was deployed in the company's server room, running a local AI model. No traffic could leave the network, and no schemas or data were disclosed to third parties. This machine hosted the lightweight server application on startup and allowed users to access it over the network.
Business Outcomes
Employees were able to access the chat window over the network via an internal website and query data themselves, relieving the IT employee from answering most query requests. Data could be retrieved significantly faster and with less friction. Because of this, operational decisions could be made more quickly and effectively. Over time, it also encouraged more teams to use data in their decision-making, simply because it was easier to access.
Future Enhancements
While the current system already enables reliable natural language querying of SQL databases, several meaningful enhancements would improve it further.
1. Conversational follow-up queries
One next step is to enable deeper multi-turn conversations with the data. Instead of treating each query independently, the system would maintain context across follow-up questions such as "break that down by region" or "compare that to last quarter." This would make the experience closer to a true AI data analyst rather than a single-query tool.
2. Automated data visualization
To improve how results are displayed, future versions could support automatic chart and graph generation based on query results.
3. Natural language report generation
Beyond answering individual questions, the system could generate full narrative reports from a single prompt. For example, a user could request "summarize Q2 performance" and receive a structured written report with key metrics, insights, and supporting data tables.
4. Improved schema understanding and data mapping
The AI's understanding of complex schemas could be improved with richer metadata mapping, including business-friendly terminology, relationships between tables, and semantic layer definitions. This would improve accuracy and reduce ambiguity in generated SQL queries.
5. Role-based access and governance controls
To support enterprise-scale deployment, future enhancements could include permissioning. Different users would have access to different tables, fields, or levels of data, ensuring secure and compliant use of AI-generated queries.
Lessons Learned
This project showed that database quality plays a major role in system performance. Even with a strong AI model, poorly structured SQL schemas required extra work in mapping and interpretation to ensure reliable results.
A key challenge was bridging the gap between how users describe data and how it is stored in the database. We also learned that user queries need to align closely with the terminology used in the schema. A short training session for users significantly improved performance and the overall experience with the system.
AI model selection was also very important. Stronger local models, optimized for SQL, significantly improved instruction following and SQL generation quality.
On the implementation side, the system could be built quickly, with a working version delivered in a few weeks. The chosen hardware met performance needs but was slightly overpowered, which suggests future deployments could be more cost-efficient.
Conclusion
Overall, this project replaced a slow, manual reporting process with a much more direct way for people to get the information they need. Instead of relying on a single technical resource to pull data from SQL databases, employees can now ask questions in plain language and get immediate, usable answers.
This shift reduced a major bottleneck, made reporting more consistent, and gave the IT employee more time for other tasks rather than repetitive data requests. Over time, it also encouraged more teams to use data in their decision-making, because it was simply easier to access.
If you are looking to streamline how teams interact with internal data, we would be happy to talk through what a similar setup could look like for your organization.