“I just want to talk to my database: ask a question and get an answer.”
-- Statement from a real client.
Sound familiar? This paper takes a practical, high-level, developer-friendly look at Oracle SELECT AI: what it does well, what it needs from you, and how APEX (and other) developers can use it responsibly to create genuinely useful applications.
Oracle SELECT AI allows users to query database data using natural language, with the database translating intent into SQL through large language models (LLMs). For data teams and developers, this capability is compelling, but it is not a simple on/off feature.
SELECT AI is a database-native capability that depends on schema design, metadata quality, security scoping, and thoughtful question or prompt design. When implemented with care, it can make it easier for users to ask ad‑hoc questions of their data and get accurate, useful answers without first designing a report or writing SQL. When implemented casually, it can confuse users, produce misleading results, and create governance concerns.
This article explains what SELECT AI does, what it requires, and how to decide whether it is appropriate for your applications and users.
Short answer: No. And that’s a good thing.
SELECT AI is not a toggle or a chatbot feature to be layered on top of your data. It is a capability that reflects the quality and clarity of your data model and metadata.
What SELECT AI needs to succeed: Well-designed schemas and views - Clear table and column names - Meaningful comments and annotations - Carefully scoped access to data objects - Ongoing tuning and review
What SELECT AI is good for: Exploratory questions - Ad-hoc analysis - Learning and understanding data
What it is not good for: Regulatory or audit-critical reporting - Precision metrics with strict definitions - Replacing governed dashboards and reports.
Takeaway: SELECT AI can accelerate insight, but only if one first invests in data clarity and governance. If your data is not ready to be read like a sentence, would a lay user understand what your data table and columns represent? Then your data is not ready to be queried like a conversation. AI is not an exact science, neither is SELECT AI.
This was a question from a real client: “I just want to talk to my database.” He is right. He talks to Google, Siri, and Alexa. Why not his database? Why be bothered with all the SQL?
End users – the business users – increasingly expect conversational interfaces. They ask questions in natural language of search engines, digital assistants, and, most recently, with AI tools, and now they want the same experience from enterprise data applications. They want to talk to their database and get real, correct answers. Traditionally, this gap has been filled by us, analysts and developers, translating questions into SQL, dashboards, or reports. That translation layer introduces delay, ambiguity, and cost.
SELECT AI addresses this gap directly inside the database. Instead of waiting for a development cycle, users look to AI for immediate results. With SELECT AI, instead of exporting data to external AI tools, users can ask questions about their data where it lives, governed by database security, metadata, and access controls.
APEX (and other) developers sit at the intersection of data and users. We already translate business requirements (questions) into SQL, reports, charts, and dashboards. SELECT AI does not replace that role. It changes where the translation happens.
Instead of:
User → You (Developer) → SQL → Result
We can increasingly support:
User → Natural Language → SQL → Result
SELECT AI works best when your schema already reads like natural language English. Is your data “natural language”? If not, you need to provide translation via metadata, annotations, views and careful profile creation. Keep reading!
With SELECT AI, the job role shifts from coding interfaces to perfecting metadata and crafting profiles to optimize SELECT AI results for the intended use case. That’s powerful, but only if the database understands the language of your data.
SELECT AI is a feature of Oracle Autonomous Database that allows natural language interaction with relational data. It is implemented through the DBMS_CLOUD_AI package and exposed through a simple SQL interface:
SELECT AI <action> <natural language prompt>;
You issue prompts using SQL, and SELECT AI uses an LLM to generate, execute, and/or explain SQL.
SELECT AI runsql "give me the top 5 fish species by catch weight";
Key points APEX developers should know. SELECT AI runs inside the database. It respects database security and object access, and it relies heavily on metadata. SELECT AI is not (yet) an APEX-native feature, but it integrates cleanly, as it is just another SQL command.
In fact, every SELECT AI SQL command is a DBMS_CLOUD_AI package.procedure call behind the scenes.
SELECT AI runsql "give me the top 5 fish species by catch weight";
It's the same as:
BEGIN
DBMS_CLOUD_AI.GENERATE(
prompt => ' give me the top 5 fish species by catch weight ',
action => 'runsql',
profile_name => ‘MY_FISHDATA_PROFILE’ );
END;
As simple SQL or PL/SQL commands, SELECT can easily be integrated in the same manner as any other command in our database applications.
Figure 1 – SELECT AI flow (credit: Oracle Corporation)
At runtime, SELECT AI combines:
The user asks a question. SELECT AI uses your profile to augment that question with metadata from your database, and sends that prompt to the LLM, also defined in your profile. The LLM proposes, or generates, SQL. Depending on your SELECT AI action, the database validates and runs it - runsql. You can see the SQL - showsql, ask SELECT AI to explain it - explainsql, or reject it. Maybe you ask the question a different way and repeat the cycle.
SELECT AI showsql "how many species were recorded in 2023";
ORA-00923: FROM keyword not found where expected https://docs.oracle.co
m/error-help/db/ora-00923/
In a SELECT or REVOKE statement, the keyword FROM was either missing, m
isplaced, or misspelled. The keyword FROM must follow the last selected
item in a SELECT statement or the privileges in a REVOKE statement
Error at Line: 1 Column: 17
Oops, you need to set the SELECT AI profile first. That gives SELECT AI the directions it needs.
BEGIN
DBMS_CLOUD_AI.SET_PROFILE(profile_name => ‘MY_FISHDATA_PROFILE’ );
END;
Now that our profile is set, the SELECT AI command is recognized.
SELECT AI showsql "how many species were recorded in 2023";
SELECT COUNT(DISTINCT fdv."SPECIES_ITIS") AS species_count
FROM "THTECH"."FISH_DATA_V" fdv
WHERE fdv."YEAR" = 2023
A decent response. We personally may have constructed that SQL differently, but it works.
We may not care about the SQL, though we should; this is AI-generated and may not be correct. Let’s just run it via runsql.
SELECT AI runsql "how many species were recorded in 2023";
The results are correct, as expected. So how did SELECT AI arrive at this SQL? Let’s see via explainsql.
SELECT AI explainsql "how many species were recorded in 2023"; ```oracle
SELECT COUNT(DISTINCT fdv."SPECIES_ITIS") AS "SPECIES_COUNT"
FROM "THTECH"."FISH_DATA_V" fdv
WHERE fdv."YEAR" = 2023;
```
**Detailed Explanation:**
- **Purpose**: This query calculates the total number of unique fish sp
ecies recorded in the year 2023 based on the ITIS codes in the "FISH_DA
TA_V" table.
- **SELECT Clause**: Uses `COUNT(DISTINCT fdv."SPECIES_ITIS")` to count
the distinct values of the "SPECIES_ITIS" column, which represents the
species ITIS codes. The result is aliased as "SPECIES_COUNT" for readab
ility.
- **FROM Clause**: References the table "THTECH"."FISH_DATA_V" with the
alias `fdv` for brevity and clarity in the query.
- **WHERE Clause**: Filters the records to include only those where the
"YEAR" column equals 2023, which is a numeric comparison since "YEAR" i
s a NUMBER type column. No string comparisons are involved, so no UPPER
() function is applied.
- **Overall**: The query ensures case sensitivity for table and column
names by enclosing them in double quotes. It uses only the provided tab
le and adheres to Oracle SQL syntax for counting distinct species in th
e specified year.
Using the narrate action will give us a text response versus the results of the generated query.
SELECT AI narrate "how many species were recorded in 2023";
In 2023, 36 different fish species were caught and recorded in the Gulf
of Mexico dataset.
Interesting that this LLM is not aware of the rename to Gulf of America. It is best that we update our metadata to reflect that change.
And if we use the chat action, we bypass the profile altogether in this case, which leads to an interesting result directly from the LLM.
SELECT AI chat "how many species were recorded in 2023";
Based on the context of our conversation about fish species released us
ing vent tools or descending devices, I'm assuming you're asking about
the number of such species recorded (e.g., documented or managed under
relevant fisheries regulations and reporting programs) in 2023.
In 2023, the Gulf of Mexico Reef Fish Fishery Management Plan (overseen
by NOAA) covered **31 species** for which descending devices or venting
tools became a mandatory onboard requirement for commercial and recreat
ional vessels as of January 13, 2023. These species are the ones most c
ommonly associated with barotrauma mitigation and release reporting in
programs like Return 'Em Right and the Marine Recreational Information
Program (MRIP). The full list includes various snappers (e.g., red snap
per, vermilion snapper), groupers (e.g., gag grouper, red grouper), til
efishes, jacks, triggerfish, and hogfish.
If this isn't the context or data source you meant (e.g., if you're ref
erring to a specific region like the Atlantic, a particular study/app,
global fish species discoveries, or something else entirely), please pr
ovide more details for a more accurate answer! Always refer to official
sources like NOAA for the latest fisheries data.
Had I used the chat action first, I would have gotten a totally different answer, as SELECT AI would have no knowledge of any prior question or context regarding fish species. Chat is a convenience feature, not a data feature. What does the LLM think with no knowledge of your data?
That showsql transparency is critical. showsql is your code review. As a developer, you are never blindly trusting AI. You are inspecting its work. As a developer, you can likely see whether the generated SQL is correct or not. You can run it and discern if the results are correct according to the question you meant to ask. You can adjust your question with the intent, or hope, of getting better results.
In my experience, on a simple data model, fully commented and annotated using views to translate non-intuitive names into natural language recognizable ones, SELECT AI was great on simple questions, as above. How many A in X? Or, what are the top five A in X? Different LLMs came up with different SQL, but pretty good results.
Yet it was significantly less so when the questions became more complicated. What are the top five A in X, by C, D, and E? In my experience, different LLMs (with identical SELECT AI profile except for the LLM) interpreted such a question differently and created different groupings in the SQL. Some used a single WITH, some used multiple WITH clauses, sometimes different columns in the GROUP BY, etc. Further, if I simply added a comma to the question, some LLMs would generate significantly different SQL. Bottom line, the results were not predictable.
Think: Can you honestly put SELECT AI, or any AI, results in front of every one of your end users? What questions will they ask? How complex will those questions be? In my case, the decision was (had to be) that an untethered SELECT AI interface was not good enough to put in front of non-tech-savvy end users. For this use case and a very broad one, not a good idea. Your mileage, on your data set, will vary. SELECT AI is powerful, but in my experience, for my use case, not 100% because of the danger of generating incorrect SQL for the intended question.
If you wouldn’t trust a junior developer’s SQL without reviewing it, don’t trust SQL generated by an LLM without using showsql to validate it.
Use SELECT AI in applications with care!
A SELECT AI profile defines database objects, an AI service, and an LLM that SELECT AI will work with.
A SELECT AI profile defines:
A most general Create Profile statement looks like this:
BEGIN
DBMS_CLOUD_AI.CREATE_PROFILE(
profile_name => 'FISHDATA_OCIGENAI_COHERE_PROFILE',
attributes => '{ "provider": "oci",
"region":"us-chicago-1",
"model":"cohere.command-a-03-2025",
"credential_name": "THTECHACE_OCI_GENAI_CRED",
"comments":"true",
"constraints":"true",
"case_sensitive_values": "false",
"annotations":"true",
"enforce_object_list":"true",
"object_list": [{"owner": "thtech", "name": "FISH_DATA_V"}]
}',
description => 'AI profile w a summary view only, to use OCI Gen AI, cohere.command-r-plus-08-2024 model, THTECHACE, for SQL translation'
);
END;
/
This created a profile using the Oracle OC Generative AI Service in the Chicago region, using an established web credential, a Cohere LLM. Further, the profile directs SELECT AI to use the comments, constraints, and annotations, ignore case, and only use the listed database object, and a single view.
Configuration parameters and attributes differ depending on the AI service, LLM, and specific SELECT AI action to be performed. See the Use Select AI for Natural Language Interaction with your Database online documentation, and the Manage AI Profiles section for complete details on profile creation for supported AI providers.
Think of profiles as guardrails. For practical, real-life applications, one should almost always use tightly scoped profiles – specific sets of database objects for specific use cases. Several profiles, one for each business topic, are likely more effective than a single profile that tries to cover all subjects.
If SELECT AI results feel “random,” it’s usually a profile problem. The need is to improve the profile, and/or to improve the metadata it references. Issues like the Gulf of Mexico versus the Gulf of America reference in my examples above may be fixed by annotations or improved comments, or better metadata. More grievous errors many need more significant profile changes – add a view, change column names, add constraints, etc.
It is essential to read and absorb the SELECT AI Profile documentation. There are many attributes, each of which has an important role in directing SELECT AI on how to interpret your data and generate SQL or otherwise act on it. Smart, strategically constructed profiles significantly improve SELECT AI results.
While SELECT AI supports many actions, and likely more will be added, these few stand out for application use. We briefly illustrated them in action above. Here is a bit more information on the SELECT AI actions most commonly used in applications or chat-like conversational interfaces:
SELECT AI needs metadata to make sense of your data. It does not intuitively know your data model or your data. You need to help it along. In general, better-quality metadata yields better SELECT AI results.
Best practices that actually matter:
Be verbose with comments and annotations. This is your chance to tell SELECT AI what your data means. For example, use this comment text:
COMMENT ON COLUMN fish_data_v.catch_weight
IS 'Total catch weight in metric tons; excludes discarded bycatch';
Versus this more general comment, which omits the exclusion that SELECT AI would not know otherwise:
COMMENT ON COLUMN fish_data_v.catch_weight
IS 'Total catch weight in metric tons';
One well-documented, annotated view beats an entire schema full of raw tables of column names that make no sense to someone outside of your business.
SELECT AI can be configured to save conversations, or to use RAG and vectors to improve results in cases where data is in documents or other vector-amenable data formats, all by adjusting the parameters and attributes in the DBMS_CLOUD_AI.CREATE_PROFILE statement. Different profile parameters and attributes apply to each case. Long-term conversations are useful when users are allowed to ask follow-up questions. Use of vectors and RAG is useful when answers require documents or text outside of the database.
For most applications, start simple. Add conversations and RAG only when the use case demands it. RAG and vectors come into play when your data is in documents, wherever they may be stored, in-database, external reference, or object store.
Figure 2 – SELECT AI flow with RAG and Vectors
SELECT AI isn’t only about generating queries from natural language questions. There are also commands to:
SELECT AI summarize "<long document text>";
SELECT AI translate "<long some language document text>";
BEGIN
DBMS_CLOUD_AI.GENERATE_SYNTHETIC_DATA(
profile_name => 'GENAI',
object_name => 'Director',
owner_name => 'ADB_USER',
record_count => 5
);
END;
/
These features can be powerful developer tools, even if end users never see them. Full details of these options are not addressed here, but can be found in the Oracle documentation SELECT AI examples.
The real question isn’t whether SELECT AI works. It is more a matter of do you have a sound use case, and have you, the developer, done adequate preparation on your data model, annotations, metadata, and profile to enable SELECT AI to serve that use case with reasonable, acceptable results.
The checklist:
This last point is critical. SELECT AI is generative AI to generate SQL and return results out of your database. It is not an exact science. In many cases, this is acceptable. In many others, it is not.
Developers should assume:
Callout: Natural language is flexible. The same question can be asked many different ways. Data is not. Your application needs to bridge that gap.
SELECT AI integrates cleanly with APEX today, and APEX itself is gaining native natural language features. Not every problem, nor every application, needs SELECT AI, or AI at all. It’s all about choosing the right use case. APEX is an ideal front-end for SELECT AI-driven conversations because APEX works on Oracle SQL and PL/SQL, and SELECT AI is essentially a SQL or PL/SQL command.
Use SELECT AI when:
Skip it, use another tool, maybe not an AI tool at all, when:
The Oracle SELECT AI is rapidly building more features with each database release. Many commands have been backported to Oracle Database 19c. If you enter this realm of AI and SELECT AI specifically, do the research to keep current on the offerings. Read the SELECT AI documentation, read the database release notes for new SELECT AI features, attend the SELECT AI Office Hours, search for and actually do all Oracle LiveLabs that involve SELECT AI. Read the SELECT AI blogs from Mark Hornick and others. There is plenty of help out there to help you succeed in your adoption of SELECT AI - use it.
Oracle SELECT AI is a serious, database-native capability—not a novelty feature. For developers, it aligns naturally with what we already do (or should be doing) well: designing clean data models, adding meaning through metadata, and building thoughtful user experiences.
SELECT AI does not eliminate the need for good SQL or good application design. Instead, it amplifies both, for better or worse. Teams that invest in clarity, scoping, and guardrails – object documentation and careful profile construction - will see meaningful, useful benefits. Teams that treat SELECT AI as a switch to flip will struggle. SELECT AI is not something you turn on. It’s something you strategically plan and design for.
Used wisely, SELECT AI helps end users feel like they are finally “talking to the database.”
The real work is proper preparation to ensure the database has something natural-language sensible to say.
Happy Holidays! 🎄
Join OraPub, Viscosity’s training hub for Oracle professionals, packed with expert-led courses and exclusive paid member benefits.
Check out Viscosity’s event page for upcoming virtual and on-site training opportunities.