When a database query beats a language model
Which customers are about to leave is a query, and somebody could write it this week. How to tell a reporting gap from an AI project.
Somebody asks for “an AI that tells us which customers are about to leave”. What they’ve 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 and nobody has written the query.
I sell AI work and turn a lot of it into something cheaper. Here’s 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.
A database query is for facts you already hold in rows. It’s exact, it costs next to nothing to run, and you can show an auditor the line that produced the number.
Ask a language model to count, sum or filter and you’ll get something that looks like an answer, now and then wrong in a way nobody catches. It’s slower than the query and it bills by the question.
Four questions
Is the answer already in structured data? If the facts are in tables, you want a query, a report or a dashboard.
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.
Would a rule cover it? If you can write the logic as four lines of conditions, write the four lines. 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” won’t survive a complaint.
If all four point the same way, you’ve got a reporting gap, about a week of work, and no AI project.
Where the model is the right tool
The boundary is unstructured input. Once the facts are in sentences, recordings or documents, the query has nothing to run against.
On one platform I built, users submit their entries as ordinary sentences in a chat tool, so a model turns each one into a structured record. From that point on everything is a query again: the totals, the audit trail and the reports. The case study has the count.
That’s the design I reach for first: the model sits at the edge and turns mess into rows, and the arithmetic, the rules and the record stay in the database. When the model’s output feeds a number somebody will act on, it gets reconciled against that record before anyone sees it.
The natural-language front end
One hybrid is worth having: staff ask questions in plain English, a model writes the query, and the answer still comes from the database, so the figure on the screen is one somebody can trace back to the rows that produced it and defend in a meeting. Don’t hand the model a spreadsheet and ask it to do the sums itself, and build this once the plain reports exist.
Why this gets missed
There’s no 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.
If you suspect that’s what’s on your desk, ask what the system would do with the language model taken out. An answer of “the same thing, faster” saves you the build, and costs you about a week of somebody writing the query.