Select AI in Autonomous Database: Natural Language to SQL

Select AI is a capability of Autonomous Database that translates natural language into SQL using a large language model, then optionally executes the result in the caller's own session. The architectural point that matters before any feature detail: the model writes the query, but the database runs it under the asking user's identity, privileges, and row level policies. The language model never holds credentials and never sees query results unless you explicitly use the narration action. That division of labor is what makes the feature governable, and it is the detail to verify first in any security review.

This article is part of our complete guide to AI on OCI, and it sits beside the other in database AI capability, vector search in 23ai, which answers a different question: vector search retrieves meaning from unstructured content, Select AI queries structured tables in plain language.

How it works: the AI profile

Everything hangs off an AI profile, a named configuration object that declares three things: which model provider to use, the hosted models of the OCI Generative AI service being the natural choice when prompts must stay inside the tenancy, which schemas and tables the feature may consider, and how the conversation should behave. Creating a profile is a privileged act, and that is correct: the profile is where governance lives, because it defines exactly what the model can learn about your data model and nothing more.

When a user asks a question, the database assembles a prompt containing the question plus the metadata of the profiled tables, names, columns, types, and comments, sends it to the configured model, and receives SQL back. What travels to the model is metadata and the question text, not table contents. That boundary is the feature's core privacy property, and also its accuracy ceiling: the model can only be as right as your schema is legible.

The actions: ask the same question five ways

Select AI exposes a small set of actions that turn one capability into several distinct tools. The runsql action generates the SQL and executes it, returning rows, the default analytics experience. The showsql action returns the generated SQL without running it, which is the trust building tool: analysts inspect before they execute. The explainsql action has the model annotate what the query does, useful for teams learning an unfamiliar schema. The narrate action runs the query and has the model summarize the results in prose, the one action where data does flow to the model, and therefore the one to govern separately. And the chat action is general model conversation without schema context at all. The progression for a cautious rollout is deliberate: start with showsql, graduate to runsql when the generated queries earn it, and permit narrate only for data classified to tolerate it.

What accuracy actually depends on

Text to SQL accuracy is not a model property; it is a schema property. The model reads your table names, column names, and comments the way a new analyst would on their first day, and it fails the same ways: cryptic names produce wrong joins, undocumented status codes produce wrong filters, and a hundred table schema produces wandering attention. The teams that get strong results treat the schema as the prompt.

• Scope ruthlessly. Profile a curated set of tables or views, not the whole schema. Twenty well named tables beat four hundred real ones.
• Comment everything profiled. Table and column comments travel with the metadata, and they are the highest leverage accuracy investment available.
• Present views, not raw tables. A semantic layer of clean views with business names hides the join complexity the model most often gets wrong.
• Measure with a question set. Fifty real business questions with known correct answers, scored before rollout and after every schema or model change.

Select AI against the alternatives

These are complements more often than rivals. Select AI excels at the long tail of ad hoc questions that never justify a dashboard, while the BI layer keeps owning the curated, repeated views of the business. The custom build is justified when text to SQL is a product feature with its own UX, not an internal capability.

A rollout framework

The failure modes, named

Text to SQL failures are not random; they cluster into four recognizable shapes, and naming them is most of catching them. The wrong join is the classic: two plausible paths between tables, and the model picks the one that double counts. The wrong filter is subtler: a status column whose codes the model guesses at, returning active records when the question meant completed ones. The wrong grain produces numbers that are correct and misleading at once, daily figures summed where the question wanted distinct customers. And the confident hallucination invents a column that does not exist, which at least fails loudly at parse time, making it the most honest failure of the four. Two properties make these manageable. They are systematic, the same schema ambiguity produces the same wrong query for everyone, so fixing the schema fixes the fleet. And they are inspectable, because showsql exposes the query for review, which is something a human analyst's mental arithmetic never offered. The golden question set turns both properties into a process: failures become test cases, schema fixes become measurable improvements, and accuracy becomes a number that trends instead of an opinion that circulates.

Cost behavior

Select AI's costs split cleanly in two. The model side bills per token through whatever provider the profile names, and the tokens per question are modest, schema metadata plus a question in, a query out, so even heavy analytical use rarely makes the model line significant against the estate. The database side is where the real money moves, because generated queries are still queries: an enthusiastic exploration session can scan tables a dashboard never would, and a wrong grain query against a large fact table burns real compute producing a wrong answer. The controls are familiar database governance rather than anything AI specific: resource management plans that cap runaway queries, consumer groups that keep exploratory traffic from crowding production workloads, and the auto scaling behavior of Autonomous Database absorbing legitimate bursts. Meter the feature like a workload, not a novelty, and fold it into the same consumption reviews as everything else in the AI cost program. In practice the spend conversation is short, and shorter than the one about the analyst hours the feature returns.

Governance: the questions to answer in writing

Three questions deserve documented answers before the feature meets users. What leaves the database: schema metadata and question text always, result rows only under narrate, and the model provider's retention terms apply to whatever travels. Who can ask: profile access is grantable, and the right grant model usually mirrors existing reporting roles rather than inventing new ones. And what gets audited: generated SQL executes as ordinary SQL under the asking user, so existing audit policy already captures it, but the question text itself is worth logging too, because "what people ask and cannot get answered" turns out to be the best product backlog the data team has ever had. The broader boundary design for AI features sits in governing AI workloads on OCI.

The independent view

Select AI is one of the strongest arguments for the converged database thesis: the feature is only this governable because it lives where the data, the identity model, and the audit trail already are. It is also a feature whose success is decided by unglamorous schema work that no demo ever shows. Our Autonomous Database practice delivers that work, the semantic views, the profiles, the question set evaluation, and the governance paper trail, on a fixed Project fee, with Managed Monthly operation afterward for estates that want the capability kept healthy as schemas evolve.