AI on Oracle: Select AI, 23ai Vector Search & Autonomous Database
If your organisation runs Oracle, the most useful AI capability you have is probably already sitting inside a database you own. That is not marketing enthusiasm — it is a practical observation about where enterprise data actually lives. The customers, orders, contracts, and support history you would want an AI system to reason over are in Oracle schemas, governed by permissions your security team already trusts. Oracle's recent AI features let you act on that data without first shipping it somewhere else, and that changes the risk calculation considerably.
This article is an honest walk through the three pieces people conflate — Select AI, 23ai vector search, and Autonomous Database — what each one does, where it genuinely helps, and where the marketing runs ahead of the engineering.
23ai vector search: RAG without a second database
Oracle Database 23ai added a native VECTOR data type and a set of operators for similarity search. In plain terms: you can store an embedding — the numeric fingerprint of a chunk of text — in a column next to the row it came from, and query for the rows whose embeddings are closest to a question. That is the retrieval half of retrieval-augmented generation, done in SQL.
The significance is architectural. The common RAG pattern bolts a separate vector database alongside your system of record, which means a second store to secure, back up, keep in sync, and reconcile when the two disagree. Keeping vectors in the same database as the source data removes that whole class of problem. Your embeddings inherit the row-level access controls, the backups, the Data Guard standby, and the audit trail you already run. A user who cannot see a row cannot retrieve its vector either, because it is the same row.
Practically, you get VECTOR_DISTANCE with the usual metrics (cosine, dot product, Euclidean), and vector indexes — an in-memory neighbour-graph index (HNSW) for speed and an inverted-file variant (IVF) for larger sets that will not fit in memory. The DBMS_VECTOR_CHAIN package can chunk documents, generate embeddings by calling a model, and run the whole pipeline from within the database. You can even load an embedding model in ONNX format directly into the database so the vectors never leave the box.
Where does the honesty come in? Vector search in Oracle is a genuinely good retrieval engine, but it is not a magic quality dial. Retrieval quality still depends on how you chunk documents, which embedding model you choose, and whether your source content is any good — exactly as it does anywhere else. The database location solves the governance and operational problem, not the relevance problem. We cover the relevance side in depth in our guide to RAG in production.
Select AI: natural language to SQL, with guardrails
Select AI, part of Autonomous Database, lets a user ask a question in English and have the database generate and run the SQL. You create an AI profile that names a credential and an LLM provider — OCI Generative AI, or an external provider — and then a statement like SELECT AI 'what were total sales by region last quarter' returns rows, not a chatbot paragraph. Variants let you see the generated SQL before running it, or get a narrated summary of the result.
The reason this is more interesting than the usual "natural language to SQL" demo is what it does not send to the model. Select AI passes metadata — table and column names, comments, relationships — to the LLM to help it write the query, but the actual data stays in the database; the SQL executes locally under the calling user's privileges. So a well-scoped profile cannot return data the user is not entitled to, because the query runs as them. That is a materially better security story than pasting rows into a chat window.
It is not a self-serve analytics replacement, and treating it as one is the fastest way to be disappointed. The generated SQL is only as good as the model's understanding of your schema, which means the quiet, unglamorous work of naming things well and adding column comments is what determines whether the answers are trustworthy. On a clean, well-documented star schema it is genuinely useful. Pointed at a cryptic legacy schema with columns named FLG1 through FLG9, it will confidently produce plausible, wrong answers. Newer versions also fold in RAG so a profile can combine your vector store with generated SQL, which widens the range of questions it can handle — but the schema-hygiene caveat does not go away.
Autonomous Database: where this is easiest, not where it is confined
People muddle Autonomous Database into the AI story, so it is worth separating. Autonomous Database is Oracle's self-managing, cloud-hosted database service. Select AI is a feature of it. Vector search, by contrast, is a feature of Database 23ai and runs wherever 23ai runs — Autonomous, OCI Base Database, or your own on-premises 23ai.
The upshot: if you are already on Autonomous, the AI features are close to a switch you turn on, and that convenience is real. If you run Oracle on-premises or on another cloud, vector search is available to you on 23ai, while Select AI specifically is an Autonomous feature. Deciding whether the AI capabilities justify a move to Autonomous is a genuine architectural question with cost, control, and data-residency dimensions — the kind of trade-off we work through on our Oracle Database & DBA support engagements rather than answer with a default.
A sensible first project
The lowest-risk way to get real value is to pick one internal use case where retrieval is the whole point: search over your own policy documents, contracts, or support history, answered with citations back to the source. It exercises the 23ai vector features, it produces something people use daily, and — crucially — a wrong answer is visibly wrong because every claim links to a document a human can check. That is a very different risk profile from letting a model take an action unsupervised.
From there, Select AI over a clean reporting schema is a natural second step, because the same team now understands both the value and the failure modes. Build the operational discipline early — versioned prompts, evaluation against real questions, monitoring of what users actually ask — rather than retrofitting it once the pilot is popular. That discipline is the subject of our writing on getting models to production.
Where the value really is
The pattern across all three features is the same, and it is why Oracle's AI story is stronger than a feature list suggests: the value is in keeping AI close to governed data rather than exporting that data to a separate AI stack. For enterprises whose crown-jewel data is already in Oracle, that removes the single biggest objection to production AI — the data-movement and access-control problem — and lets you spend your effort on the parts that actually determine success: data quality, retrieval relevance, and honest evaluation.
None of it is automatic. It rewards teams who treat it as engineering: clean schemas, good source content, measured quality, and a human in the loop where decisions matter. If you want to talk through where your Oracle estate could carry an AI use case sensibly, that intersection is exactly what our AI & machine learning and Oracle practices are built to cover.