Build or buy: the honest case for each in text to SQL solution

Buy a text to SQL solution when your data sits in one BI platform, your metric definitions already live in it, and fewer than fifty internal people will ask questions. Build when questions cross systems, when permissions are per-row rather than per-dashboard, or when answers are shown to customers. Most organisations end up doing both, in that order.

What follows is the decision framework we use on first calls: the three options as they really exist, a five-question test, a three-year cost comparison, and the failure mode each choice carries.

The three options, defined

A text to SQL solution is any system that converts a natural-language question into SQL, runs it against a database and returns the result. That definition covers three very different products.

Buying means switching on the natural-language feature inside a BI platform you already licence, or adopting a packaged assistant that connects to your warehouse. The model, the interface and the metric mapping come from the vendor. You configure rather than engineer.

Building means assembling the parts yourself: a semantic layer that defines your metrics, a generation step, a validation step that rejects unsafe or expensive SQL, execution under the asker's identity, and an evaluation suite that gates every release. You own each piece and can change any of them.

Integrating, the option people forget, means buying the interface and building the layer underneath it. Your metric definitions live in a version-controlled semantic layer and several tools consume them. dbt documents this pattern in its semantic layer documentation, where metrics are defined once and queried by different downstream applications. It is the least fashionable answer and frequently the right one.

The choice is not really between vendors. It is between who gets to decide what your numbers mean, and the answer has a long half-life. Interfaces get replaced every few years without much pain; a metric dictionary that only one tool can read is the thing that makes a migration expensive five years from now.

Buy, build or integrate: a side-by-side

A five-question test

Score one point for each question you answer yes to. Zero or one point means buy. Two or three means integrate. Four or five means build.

• Do the questions cross systems? If a common question needs the warehouse plus a live operational database or a third-party API, a platform feature will not reach it.
• Are permissions per row rather than per report? A regional manager who may see only their region needs identity-aware execution, not a filtered dashboard.
• Will answers leave your organisation? Anything shown to a customer or a partner needs validation, citation of the query and an audit trail that most packaged features do not expose.
• Does your business argue about definitions? If revenue means three things in three systems, you need a layer you control, because the arguments will continue after launch.
• Is question volume high and growing? Above a few thousand questions a month, per-seat licensing and unbounded query cost both start to hurt, and you want control of routing, caching and limits.

The test is deliberately blunt. It is not a maturity model, and a company with a good data team can still be a clear buy if its questions are simple. The build versus buy comparison applies the same logic across AI decisions generally, and the build, buy or integrate glossary entry is a short version to circulate.

The honest case for buying

Packaged natural-language querying has improved. If your organisation runs on a single BI platform, your semantic model already exists inside it, and your users are analysts rather than executives, switching the feature on will answer a genuine share of questions within a fortnight for the price of a licence uplift. That is a good outcome, and no consultancy should talk you out of it.

Buying is also correct as a diagnostic. Three months of logs from a packaged tool tell you which questions people actually ask, which is the single most useful input into a build. Buy first, read the logs, then decide whether the remainder justifies engineering. The one thing to insist on during that period is that the questions people type are logged somewhere you can export, because those logs are worth more than the tool itself when you come to write a specification.

The honest case for building

Building wins when correctness carries consequences. If an answer feeds a regulatory return, a customer invoice or a pricing decision, you need to control what the system does when it is uncertain, and packaged tools rarely let you. Building also wins when your permission model is genuinely per row, because retrofitting identity-aware execution onto a tool that assumes a service account is not a configuration exercise. The same applies to refusal behaviour: a system that must decline a question rather than guess at it needs a validation step you control, and that step is where most of the engineering value in a custom build sits.

The third case is product. If natural-language querying is a feature your own customers will use, it is part of your product surface and has to meet your latency, branding and support standards. That is a build, and it is usually paired with an in-product assistant rather than a separate analytics tool.

When the answer is genuinely both

The most common outcome in the businesses we work with is a split by audience. Analysts keep the platform feature, because they can read SQL and correct it themselves. Everyone else gets a narrower, governed interface built over a semantic layer, exposing a smaller set of certified metrics with the query shown and a clear refusal when a question is out of scope.

That split costs less than it sounds, because both surfaces read the same definitions. It also moves the argument from tooling to governance, which is where it belongs. Delivering the second surface where people already work, rather than in another tab, is covered in conversational analytics in Slack and Teams.

What does each option cost over three years?

Buying is licence uplift plus the cost of metric drift, which is real but hard to invoice. Building with us through natural language data querying starts at $12,500 or ₹8 lakh and runs to $38,500 or ₹25.6 lakh, with usage on your own accounts and a Care Plan from $1,000 or ₹68,000 a month. Over three years the build typically overtakes a per-seat licence somewhere between eighty and two hundred users, depending on the licence.

If you want the decision made on evidence rather than a spreadsheet, a ten-day Sprint Zero at $3,250 or ₹2 lakh, credited against the build, produces the metric inventory and a golden question set you can run against a trial of any platform. Starting figures for every programme are on the pricing page, and the build-side detail is in text to SQL solution cost in 2026.

Where each choice goes wrong

Buying goes wrong when the platform's definitions quietly diverge from the ones finance uses, and nobody notices because the tool is confident. It also goes wrong at renewal, when per-seat pricing meets an adoption success you were pleased about six months earlier.

Building goes wrong when it is scoped as an AI project. A team that spends eight weeks on prompts and two days on the semantic layer will ship something that demos well and is distrusted within a month. If your organisation cannot free an analyst to write and own the golden question set, do not build; the project has no way to prove it works.

Integrating goes wrong when nobody owns the layer. A shared artefact with no owner decays faster than a private one. Name the person, not the team.

What a build looks like in practice

Where querying is part of a product rather than an internal tool, the shape changes: the assistant lives inside the application, uses the same permissions as the screen the user is on, and is judged on whether people open it rather than on SQL accuracy alone. Our in-app copilot case study describes a copilot that made a field-service SaaS the tool users open first, and a customer-facing querying feature is built with the same instincts.

Related reading

How long does a text to SQL solution take sets expectations for the build path, the semantic layer post explains the asset that survives either decision, and Eazy Insights AI shows the governed-answers approach in product form.

Buy the interface if you must, but own the definitions, because that is the only part of this decision you cannot cheaply reverse.