Do We Really Need Another Text-to-SQL Startup?
There is a reasonable question behind every startup in AI analytics: why?
If you are building a text-to-SQL product in 2026, you are entering a market where some of the largest technology companies in the world are already investing heavily. Databricks has Genie. Snowflake has Cortex Analyst. The cloud providers each have their own AI and data experiences. The foundation-model companies keep getting better at generating SQL, and most of them ship a demo that turns a question into a query against a sample database.
So why would anyone build another one?
We asked ourselves exactly that question. The honest answer is this:
If Savvina were simply another interface that turns English into SQL against one data warehouse, there probably wouldn’t be much reason to build it.
That is not the problem we are trying to solve.
The giants have enormous advantages
Let’s be clear about something. Databricks, Snowflake, Microsoft, Google and the other major platforms have advantages a startup cannot manufacture overnight. They have scale, infrastructure, enterprise relationships, and mature security and governance ecosystems. When your data already lives entirely inside one of these platforms, its native AI capabilities can be a very natural choice.
Databricks, for example, integrates Genie into its wider data and AI platform and gives account administrators budgets and cost controls for it. Snowflake’s Cortex Analyst provides native natural-language analytics inside Snowflake, with its own consumption model and a security model that is already the customer’s.
Savvina is not trying to pretend these platforms do not exist. They are exactly why we had to ask ourselves whether there was a different problem worth solving.
The world doesn’t look like one warehouse
Most real companies do not have one perfectly organised analytical database. They have years of infrastructure. A CRM here. A billing database there. An operational PostgreSQL instance, a SQL Server that runs the ERP, some Snowflake, some Databricks, an S3 bucket full of exports, maybe ClickHouse for high-volume event data. And a collection of systems that nobody wants to migrate just because a new AI tool appeared.
Consider a telecom operator. Customer records live in the CRM, on PostgreSQL. Recharge transactions live in the billing system, on SQL Server. Network usage sits in ClickHouse. Campaign data was exported to S3. And the historical view lives in Snowflake or Databricks.
A platform-native assistant naturally works best when the data it needs is already inside its ecosystem. But the business does not think in databases. The business asks:
“Did customers who received the new prepaid campaign recharge more often afterwards?”
“Which postpaid packages generate the most revenue but also the most support tickets?”
“Which customer segments are moving from prepaid to postpaid?”
“What happened to package profitability after the last pricing change?”
Those questions cross organisational and technical boundaries. The customer does not care where the data lives.
That changes the question. It is no longer “can AI generate SQL?” It is:
“Can people ask questions about the data they already have, without first rebuilding their data architecture around an AI product?”
Suppose your company already has those five systems. You do not want to migrate them. You do not want to duplicate the data. You do not want to adopt a new warehouse just to experiment with natural-language analytics. You do not want your AI analytics layer to dictate which LLM you use. And you may not want your schema and business logic leaving your infrastructure at all.
You simply want to put a conversational interface over the data you already own.
You don’t necessarily need to rebuild the world to make it intelligent.
That is the space we are interested in. Savvina is designed as a self-hosted analytics layer, not another data platform. It connects to 22 data sources spanning databases, warehouses and object storage, and it gives them a common natural-language interface: centralised control over which schemas and columns the model is allowed to see, set connection by connection; validation of every generated query before it runs; and an audit trail of who asked what, through which provider, and how many tokens it took.
What it does not do yet is join across them. Each connection is queried independently through its own adapter and dialect, and a question that needs data from two systems still needs that data to land in one engine first, as we spell out in our Google Cloud guide. Cross-source querying is an area we are actively exploring, but we would rather describe that as a direction than imply it is already solved.
What we are confident about is the direction. As companies adopt more AI without wanting to rebuild their entire data estate, the value of one governed interface over everything they already have only grows.
Cost is part of the architecture
AI analytics has another problem that is easy to overlook: the question is not only whether the answer is correct, but how much it costs to get there, and whether anyone could have said so in advance.
Databricks and Snowflake both illustrate why cost is becoming part of the architecture. Databricks uses consumption-based billing for Genie products, with a per-user free allowance and usage controls, while Snowflake charges for Cortex Analyst usage and separately for the warehouse compute used to execute the generated queries. These models can make perfect sense when everything already lives inside those platforms.
But there is another architecture: bring your own model.
With Savvina, the LLM is not part of a database platform you are forced to adopt. You choose which model, which provider, and whether it is a local model through Ollama running inside your own infrastructure. You choose how much inference you want to pay for, whether repeated questions should call the model at all, and which of your own databases executes the SQL. That changes who controls the economics. Instead of every question going through one vendor’s AI service, on that vendor’s meter:
“I decide which model I use, where it runs, and how much I want to spend on inference.”
This matters most before a rollout, not after. Companies have to budget an AI initiative before they approve it, and a consumption meter on a platform’s AI service is hard to budget until people have already been using it for a while. With Savvina the bill has one variable, and it is one you already understand: the inference you buy from a provider you chose, at that provider’s published rates, or the fixed cost of a machine running a local model. Savvina adds no per-query or per-token fee of its own. Every answer is logged with its input and output token counts, per user and per provider, so a two-week pilot gives you a number you can multiply, and a finance team can set the ceiling before the tool reaches a hundred people rather than discover it afterwards.
There is one more lever. Savvina keeps a two-tier query cache: an identical question returns the cached result with no model call at all, and a semantically similar question hits a vector similarity check first and returns the cached SQL for verification. In our own testing, the number of LLM calls drops dramatically as the cache fills with the questions a team actually asks, and the log above lets you measure the effect on your own workload.
So cost is not just a pricing-page issue. It is an architectural decision.
A startup has to earn its existence
A startup should not exist simply because a large company has not built the same feature yet. It has to solve the problem differently enough that someone has a reason to choose it.
For Savvina, that means being useful when the data is not all in one place, when the infrastructure has to remain under the customer’s control, and when the customer wants to choose the models and the economics of the AI layer.
So, why another startup? Not because we think a small startup can outspend Databricks. Not because we think we can build a larger foundation model. Not because we think everyone needs another dashboard. And certainly not because text-to-SQL itself is an unsolved problem.
The interesting problem is what happens around text-to-SQL:
- Which data should the model see, and which data should it never see?
- How do you work across heterogeneous sources?
- Which model should do the reasoning, and where does it run?
- How much does every question cost, and who can find out before the bill arrives?
- How do you validate generated SQL before it reaches production data?
- How do you let someone ask a question without giving them unrestricted database access?
That is where we believe there is still room for innovation. We wrote about the governance half of that list in The SQL Was Never the Hard Part. This post is about the other half: the data, the model and the bill.
We also know where Savvina isn’t the answer
If all your data is already in Databricks and you want the deepest possible integration with Databricks, its native tooling deserves serious consideration. If you are completely invested in Snowflake, Cortex Analyst is naturally compelling. More generally, if your primary requirement is the deepest possible integration with a single cloud data platform, a native solution will often have an architectural advantage. A startup should not hide that.
The goal is not to replace every platform. It is to solve a different set of constraints. Companies do not always need another platform. Sometimes they need a layer between their existing data and the people who need answers from it.
That is the bet we are making with Savvina.
The real question
So, do we really need another text-to-SQL startup? Maybe not. We definitely do not need another product that does exactly what the existing platforms already do.
But if the problem is:
“I have data everywhere, I want to keep control of it, I want to choose my models, I don’t want to rebuild my data platform, and I want people to ask questions without becoming SQL experts…”
then we think there is still an interesting problem to solve.
And that is why we are building Savvina.
Not to compete with the giants at being giants.
To make the data architecture companies already have more accessible to the people who need to use it.
Try it
The Community edition is free, self-hosted, and open on GitHub under BSL 1.1, converting to Apache 2.0 in 2030. It runs on whichever LLM provider’s key you bring. Teams that need more seats, the full set of 22 data sources, or SSO can compare plans on the pricing page, and none of them charge per query.