For years, companies have stored vast amounts of text in their databases and been unable to do much with it. Standard database queries work on exact matches and numbers. They cannot tell you which insurance claims contain frustrated tone, which supplier emails mentioned a delivery risk, or which hotel reviews specifically praise cleanliness. Answering those questions requires something that understands language.
AI models can do this. The catch has always been cost and speed. Calling a large AI model once for every row in a million-row table is not just slow; it is prohibitively expensive for most businesses. A medium-sized data query on tens of millions of rows could consume a volume of AI processing that makes the whole operation economically pointless.
Google's approach, now published in an academic paper and already active in its BigQuery and AlloyDB database products, reframes the problem. Rather than calling a large AI model on every row, the system calls it on a small sample of roughly a thousand rows. It uses those results to train a tiny, purpose-built model that has learned the specific pattern the query is asking about. That tiny model then handles the rest of the rows locally, at a fraction of the cost and without needing specialised hardware.
The numbers are meaningful. For a one-million-row query, this approach uses around 400 times fewer AI calls than the conventional method. Query response times drop by 30 to 100 times. Across eleven different test scenarios, the accuracy of results ranged from 90% to 116% of what you would get from running the full AI model on everything. In one case involving product review analysis, the small model actually outperformed the large one, because it had been trained specifically on that data rather than treating each row as a fresh problem.
The system is not blind to its own limits. Before committing to the cheap approach, it automatically checks whether the pattern is learnable and whether the quality holds. If not, it falls back to the full AI model without the user needing to do anything. This built-in safety check matters because the technique does not work for every type of question. Questions that require connecting multiple separate concepts or multi-step reasoning will still need the full model.
What makes this significant beyond Google's own products is the direction the entire database industry is heading. Microsoft has built AI query functions directly into SQL Server 2025, which became generally available in late 2025. That product now supports semantic search and AI-powered queries written in the same SQL language database teams already use. The feature set is different from Google's proxy model approach, but the destination is the same: AI understanding of text, built directly into the database, without needing a separate system.
For businesses, this shift changes what is worth analysing. A retailer with ten million customer reviews could now identify recurring complaints about a specific product attribute at a tiny fraction of what it would have cost eighteen months ago. An insurer with a large archive of claims notes could query for a specific pattern of language without exporting data or commissioning a custom AI project. The infrastructure is moving toward the data rather than the other way around.
The remaining limitation worth noting: this only works well when there are enough examples of both answers in the data. If you are looking for something extremely rare, say, one complaint type in ten thousand rows, the system cannot learn the pattern reliably from a sample. But for the broad majority of real business questions about customer sentiment, classification, and filtering, the cost barrier has materially changed.