Most companies I meet already have the data. What they lack is a fast way to get answers out of it. The warehouse has been fed faithfully for years, and the questions keep coming from operations leads, quality engineers, and finance managers. Every question becomes a ticket, then a report request, then SQL, and by the time the dashboard is updated the question has changed.
Oracle Database 23ai, which Oracle renamed Oracle AI Database 26ai in October 2025, closes that gap in a practical way: it brings the AI to the data. Two capabilities do most of the work, and both are easier to understand than their names suggest.
Select AI: ask the warehouse in plain English
Select AI, available in Oracle Autonomous AI Database and in Oracle AI Database on-premises, lets someone type a question in ordinary language, “which production line had the highest fallout rate last month,” and get the answer from the warehouse. The database hands the question, together with a description of your schema, to a language model you choose, then runs the resulting SQL itself, under the same security and permissions that govern every other query. To write the query, the model works from the shape of your schema; your rows stay in the database. If you later ask it to narrate results or answer from documents, that content is shared with the model deliberately, under the same governance.
We are designing this now with a global electronics manufacturer. Their assembly and test operations generate large volumes of quality and reliability data, and their analysts have a running list of questions that changes weekly. Instead of another round of dashboards, the warehouse takes the question directly, with Oracle Analytics Cloud on top for visual exploration once the answer comes back. The engineering effort moves from building a report per question to building the semantic foundation once and letting the questions flow.
That phrase, semantic foundation, is where I owe you honesty from the field. Natural language to SQL lives or dies on metadata. If your table is called CUST_A and the column is CST_ID with no comment on either, the model is guessing, and some of its guesses will be confidently wrong.
The single highest-value preparation step is unglamorous: comments on tables and columns, documented joins, and a curated view layer that presents the business-ready shape of the data. In one recent engagement we found that a wide, well-described reporting view outperformed a beautifully normalized star schema for this purpose, simply because the model could read what everything meant. Metadata used to be housekeeping. It is now infrastructure.
Metadata used to be housekeeping. It is now infrastructure.
Vector Search: your documents become part of the answer
The second capability solves a different half of the same problem. A large share of what a company knows never reaches a table at all. It lives in maintenance manuals, escalation write-ups, engineering notes, and the memory of the person who fixed the machine last time.
AI Vector Search, a core feature of Oracle Database 23ai, stores the meaning of that content alongside your relational data, in the same database. When a field engineer asks about the maintenance interval for a specific machine component, the database retrieves the passages closest in meaning and the AI answers from those passages.
On another engagement we designed a field knowledge assistant on this pattern, built from the start so engineers can rely on what it says:
- Every answer carries a pointer back to the source document it came from.
- Access follows the same role-based controls the company already runs.
- New knowledge enters through a review step before the assistant is allowed to use it.
Because vectors and rows share one database, one query can do both jobs at once: find the machines with rising fault rates this quarter, and pull the engineering notes related in meaning to those faults. That combination of analytics and institutional memory in a single answer is what changes how a team works.
What 26ai means for this investment
Oracle AI Database 26ai is not a new release you have to plan a migration to. It is 23ai renamed, delivered through the 23.26.0 Release Update: the architecture is unchanged, the internal version is still 23.26.0.0.0, no application recertification is required, and the Long Term Support policy that covered 23ai carries straight over.
The practical message for anyone planning today is simple. The metadata, the curated views, and the governance you build for 23ai move forward with you. Nothing in the preparation work is throwaway.
Where I would start
Start with one question your team keeps asking, one they ask so often that everyone is tired of it. Stand up a focused proof of concept with your own data, on Autonomous AI Database or on your own on-premises estate, invest the first two weeks in metadata and the curated view layer, and put governance in the design before the first user touches it. Keep the scope small, use real data, and measure answer quality honestly. A well-scoped proof of concept like this can produce a decision in weeks.
The technology works. What decides success is the discipline around it: knowing your data estate, describing it well, and phasing the rollout so trust builds with every release. That is the work we do at Infolob, and the payoff is that routine questions get answered the same day they are asked.
For all queries, please write to:
