When a database query beats a language model
A good deal of what gets specified as AI is a query nobody wrote. How to tell the difference before you pay for the expensive version.
Somebody asks for “an AI that tells us which customers are about to leave”. What they have described, nine words in, is a query: customers whose usage fell last month and who haven’t logged in for a fortnight. The data is in the database. Nobody has written the query.
I sell AI work and I turn a fair amount of it into something cheaper. This is how I tell which is which.
What each tool is for
A language model is for language. It reads text nobody structured, copes with the hundred ways a person can phrase the same thing, and produces prose. Those are hard problems and it handles them well.
A database query is for facts you already hold in rows. It’s exact, it returns the same answer every time, it costs close to nothing to run, and you can show an auditor the line that produced the number.
The confusion starts because a language model can imitate the second job. Ask it to count, sum or filter and it will produce something that looks like an answer. It will be slower, it will cost money per question, and now and then it will be wrong in a way nobody notices.
Four questions
Is the answer already in structured data? If the facts are in tables, you want a query, a report or a dashboard. The model adds cost and takes away certainty.
Does the same input need the same output? A price, a compliance record, a stock level: these must not vary between runs. A query is deterministic by construction. A model has to be made to behave that way, and then tested to prove it does.
Would a rule cover it? If you can write the logic as four lines of conditions, write the four lines. They cost less to build, less to run, and they need no re-testing when a model version changes.
Does anyone need to explain the answer afterwards? “The system flagged it because these three fields met these thresholds” is an explanation. “The model thought so” isn’t one that survives a complaint.
Four answers pointing the same way means you don’t have an AI project. You have a reporting gap, and it’s a week of work.
Where the model earns its place
The boundary is unstructured input. The moment the facts are in sentences, recordings or documents, the query has nothing to run against, and that’s where a model changes the economics.
On one platform I built, users submitted entries as ordinary sentences in a chat tool. No query could read those. A model turns each one into a structured record, more than 79,000 as of August 2026, and from that point on everything is a query again: the totals, the audit trail, the reports. The model does the one job only it can do, and the database does the rest.
That division is the design I reach for first. Use the model at the edge, to turn mess into rows. Keep the arithmetic, the rules and the record in the database, where they’re exact and cheap. When the model’s output feeds a number somebody will act on, reconcile it against the record before anyone sees it.
The natural-language front end
There’s a fair case for one hybrid: letting staff ask questions in plain English and having a model write the query. It can work well. The thing to hold on to is that the answer still comes from the database. The model translates the question and the query produces the figure, so the figure is checkable.
The version to avoid is the one where the model is handed a spreadsheet and asked to do the sums itself.
Why this gets missed
Nobody has a budget line for “write the query we should have written three years ago”. There’s a budget line for AI. So the reporting gap gets dressed as an AI project to get funded, and the business pays for a model to do a job a query does better.
If you suspect that’s what is on your desk, ask what the system would do if the language model were taken out. If the honest answer is “the same thing, faster”, you have your answer, and you’ve saved the build.