Talk to your Data Part 3: The Potential of Natural Language

This is the last and final part of our article series covering the new MCP server by MotherDuck. We have already presented the basics and challenges in previous parts. Now, we want to conclude with our findings and comments on the current state and give an outlook on the ever-changing data landscape.

First and foremost, we think that offering an MCP server for data storage is a very powerful tool that can offer benefits to almost every role related to generating value out of data. We will outline three areas where we see the biggest potential before naming clear drawbacks. To round things up we will look at the broader changes in the data landscape when it comes to MCP.

Clear Benefacticiaries

The first area is an obvious choice. We see great value for users who know their data but they do not have the time or ability to write their own SQL, notebooks or create their own dashboards or reports. Sometimes they just want to quickly know a fact for an ad-hoc question without starting up a whole toolchain in order to get a simple answer.

This is where a conversational approach like MotherDuck’s MCP server bundled with an LLM and an interface can really shine. We still see that it would require some sort of context or memory for ad-hoc queries to be answered correctly, especially when there is a large amount of varying data available but this can be remediated successfully.

Our next group are analysts who create reports and dashboards and use Python or SQL as their usual means to interact with data. Drafting queries through a conversational interaction with the data warehouse offers a significant improvement in efficiency. Identifying matching columns, creating CTEs, and generating aggregations is done in a fraction of the time used to manually write code.

This generated code can serve as an immediate launchpad for further actions. Analysts take these optimized queries directly into their preferred BI tools or IDEs to finalize reports and drive decisions. By handling the heavy lifting of the drafting phase, MCP empowers them to focus their energy on the finer parts and deliver value.

Our final group consists of data engineers who manage the core infrastructure. Drafting ETL logic becomes a faster process with conversational inputs. Engineers can quickly generate code to apply complex filters or standardize formats across raw datasets. This removes the need to manually trace every column requirement for routine cleaning tasks.

The results can act as a reliable starting point for production pipelines. Engineers review and use these snippets on their orchestration platforms to finalize their transformations. This can accelerate the initial build phase and would leave more time to focus on system stability rather than repetitive scripting.

Drawbacks

We have already covered the immediate drawbacks and remedies for problems in the previous part. We want to summarize the drawbacks in this article. The most immediate issue is the inherent conflict between a probabilistic model and deterministic query engine. While the generated SQL is observable during interaction with the MCP server, the process remains non-deterministic: identical prompts can yield varying query logic across sessions, making it risky to rely on the agent’s interpreted results for automated reporting without a rigorous verification layer.

Context management presents a significant technical challenge as the number of tables and metadata description grows. The MotherDuck MCP server offers features to list and search tables but even with comments, connections between tables must be explicitly named since there can be assumptions that will lead to very different results or assumptions about the intended target.

These technical limitations translate into practical constraints for different user groups. Business users who rely on repeatable reports for compliance or audit purposes face risk from non-deterministic query generation. Analysts building analytical frameworks that others will maintain cannot explain generated SQL they don't fully understand themselves, and when statistical rigor requires knowing exact aggregation logic, the black box nature of LLM-generated queries becomes a liability rather than an asset. Engineers building production data pipelines requiring reliability find that probabilistic generation obscures root causes during debugging, and maintaining legacy generated SQL that nobody fully understands violates basic principles of sustainable software development.

Deploying MCP-enabled chat interfaces at organizational scale surfaces infrastructure bottlenecks that traditional data warehouses weren't designed to handle. Warehouse concurrency limits assume human analysts submitting deliberate queries, not the bursty, high-frequency query patterns generated by conversational interfaces. A single user conversation doesn't map to a single SQL query: LLMs generate multiple exploratory queries, schema inspections, and refinements before delivering an answer. Clickhouse's analysis estimates that organizations need 3-5× more query capacity than concurrent user sessions. Small teams (10-50 concurrent users) generate 30-250 queries per second, while enterprise deployments (1,000-5,000 concurrent sessions) trigger 3,000-25,000 queries per second, far exceeding typical warehouse concurrency budgets.

Scaling warehouse capacity to absorb this load becomes prohibitively expensive. Organizations pay premium prices for resources that sit idle between sporadic chat interactions, creating a cost structure fundamentally misaligned with conversational workloads. Query slots could exhaust rapidly, forcing requests into queues and degrading user experience precisely when natural language interfaces promise instant insights. Fast autoscaling could solve part of this problem, but would still drive up costs.

Query inefficiency compounds the concurrency crisis. While LLMs generate syntactically valid SQL consistently, they routinely violate database-specific optimization principles like missing partition predicates, suboptimal join ordering, and unnecessary type conversions. These queries execute correctly but consume excessive compute resources and prolong execution times. Each warehouse platform has unique optimization requirements that generic AI models don't internalize. The performance penalty varies dramatically. Similarly, the generated SQL often lacks the semantic nuance of business logic. The MCP-driven interactions serve best as a drafting phase or explorative tasks rather than a final production step. Users must actively review the observable query logic and adapt to their own toolchain to bridge the gap between a conversational answer and a reliable data pipeline or reproducible insights. Hence, the human in the loop remains a non-negotiable requirement. For use cases demanding deterministic processes, auditable logic, or transferable knowledge, MCP is not the weapon of choice.

The MCP Landscape

MotherDuck is not the only company to offer MCP capabilities or conversational approaches to interact with data. We have seen approaches from Microsoft using Copilot in Fabric, Google with BigQuery, Databricks with AI/BI Genie, and Snowflake with Cortex AI. Each takes a different path to the same goal of letting people ask questions about data in plain language.

Some require semantic models to define relationships and business meaning. Others use metadata frameworks that sit alongside your data without modifying it. A few are still exploring how AI functions fit into query execution. What they share is the need for some kind of scaffolding or harness, whether configuration files, structured metadata, or domain expertise, to guide the agent from user intent to accurate query.

This shift toward hybrid interaction, blending traditional queries with conversational interfaces, is happening across the industry. The different approaches each platform takes suggest we're still early in figuring out what works best. Comparing how these systems bridge the gap between what people ask and what data actually delivers will be an interesting topic to explore.

Closing

We have discussed the immediate advantages and drawbacks of talking to your data and presented our experiences and experiments throughout this series of articles. The initial ease of use and the seamless transition between writing natural language, observing the execution of SQL, and receiving an accurate response to our questions was a great experience.

We believe that a conversational interface is a valuable addition to our toolset and that it can offer interesting options in the near future with more optimization and more robust behavior. It will be interesting to see the results on other platforms to identify common hurdles and opportunities. We like the potential that this approach holds for different roles across the data lifecycle and value chain. What we have seen with MotherDuck's MCP server suggests that the real value comes not just from talking to your data, but from doing so within the tools that teams already use.

As the industry moves toward shared infrastructure for connecting AI systems to data, the question shifts from whether conversational interfaces will exist to whether they become integrated parts of our standard workflows. It will be interesting to see if this approach becomes a niche interest or a commodity for a broad user base.