Bringing AI to Your Data with Oracle Database
Before We Begin
If you’re new to this series, start with my first blog:
AI for Oracle DB Professionals: A Simple Mental Model to Cut Through the Noise https://sushilmotwani.com/2026/04/19/ai-for-oracle-db-professionals/
In that article, I introduced a simple framework for understanding where AI fits into the database world.
The goal of that blog was to simplify the AI landscape and provide a mental model for understanding where AI fits within the world of enterprise data and databases.
This blog is different. This blog is about taking the first step.
Where Do I Begin?
I spent a large part of my career as a DBA before moving into database architecture, cloud modernization, and strategic technology roles. Today, I spend a lot of time helping customers with database modernization, cloud adoption, AI, and data platform strategy.
What I keep hearing from DBAs and cloud architects is remarkably consistent:
“This all sounds interesting, and overwhelming at the same time. Where do I actually begin?”
That is the right question. Not because AI is unimportant. Not because DBAs are resisting change. But because the amount of AI terminology arriving all at once can feel overwhelming, almost like an AI tsunami.
Large Language Models, Vector Search, RAG, Agents, Private Agent Factory, and a seemingly endless stream of new concepts and acronyms.
Every week seems to introduce a new concept, a new product, or a new acronym.
The challenge isn’t a lack of interest. The challenge is knowing where to start.
So instead of trying to understand everything at once, I decided to find the smallest practical step.
Think about a child learning to walk. Nobody starts by running a marathon. First comes rolling, then crawling, then standing and then taking that first step.
I believe learning AI as a DBA follows a similar journey.
Bring AI to the Data
One idea immediately made sense to me:
Bring AI to the data instead of moving data somewhere else.
As database professionals, we already understand data gravity.
The data is already there. The governance is already there. The security is already there. The database is already the system of record.
Instead of starting with models and frameworks, I wanted to start with the thing DBAs already understand best:
The data.
That is one of the things that attracted me to Oracle’s AI strategy. The database stays central.
AI becomes another way to interact with the data that already lives there.
Introducing MarketPulse
To make this series practical, rather than using a generic HR or sales schema, I wanted a dataset that most people could immediately relate to and that could evolve with us throughout this learning journey. I created a new database MarketPulse as an Oracle Autonomous AI Database on Oracle Cloud Infrastructure and created a new schema called “marketpulse”.
For this post, I am keeping the focus on the structured data layer:
• Investors
• Accounts
• Holdings
• Companies
• Transactions
• Sectors
• Watchlists
• Market Prices
I also added:
• Company Profiles (JSON)
• Analyst Notes (Unstructured Text)
Those will matter later in the series. For now, the point is to keep the first experience simple and familiar.
The First Practical Step
For a traditional DBA, the first useful AI experience is Natural Language to SQL.
Oracle provides this capability through Select AI.
I am not going into the implementation details in this blog. Oracle already provides excellent documentation for that, and there is enough value simply in understanding the experience itself.
If you would like to explore the setup process, Oracle provides detailed documentation here:
Getting Started with Select AI
https://docs.oracle.com/en/cloud/paas/autonomous-database/serverless/adbsb/select-ai-get-started.html
Using Select AI Prompts
https://docs.oracle.com/en-us/iaas/autonomous-database-serverless/doc/select-ai-keyword-prompts.html
What interested me was something much simpler:
What happens when a DBA asks Oracle Database a question in plain English?
Historically, the workflow looked like this:
| Before | After |
|---|---|
| Business Question ↓ DBA Writes SQL ↓ Database Executes ↓ Answer | Business Question ↓ AI Generates SQL ↓ DBA Reviews SQL ↓ Database Executes ↓ Answer |
That is the shift.
SQL is still there. The database is still there. The DBA is still there.
The destination remains the same. The journey to get there is evolving.
My First Successful Example
I started with a simple question:
Show all technology companies.
A business user would understand that question immediately.
A DBA would understand it too.
Somewhere in the database there must be:
- Companies
- Sectors
- A relationship between them
Oracle generated the following SQL:
SELECT
"cmp"."COMPANY_NAME" AS "Company Name",
"cmp"."DESCRIPTION" AS "Company Description",
"sec"."SECTOR_NAME" AS "Sector Name"
FROM
"MARKETPULSE"."MP_COMPANIES" "cmp"
INNER JOIN "MARKETPULSE"."MP_SECTORS" "sec"
ON "cmp"."SECTOR_ID" = "sec"."SECTOR_ID"
WHERE
UPPER("sec"."SECTOR_NAME") = UPPER('technology')
What impressed me wasn’t that Oracle generated SQL.
What impressed me was that the SQL was actually reasonable.
Oracle identified the correct tables. Oracle generated the correct join condition. Oracle applied the appropriate filter.
And perhaps most interestingly, Oracle explained how it interpreted the request.
Explanation:* We join the `"MARKETPULSE"."MP_COMPANIES"` table with the `"MARKETPULSE"."MP_SECTORS"` table on the `"SECTOR_ID"` column to get the sector name for each company.
* We use the `UPPER()` function to convert both the `"SECTOR_NAME"` column and the string `'technology'` to uppercase for case-insensitive comparison, since `'technology'` is not enclosed in double quotes.
* The result will show the company name, description, and sector name for all technology companies.
The explanation showed exactly how Oracle understood the question, which tables it selected, and why it generated the SQL that it did.
Finally, Oracle executed the generated SQL and returned the expected results.
| Company | Description | Sector |
| Oracle Corporation | Enterprise software, database, cloud infrastructure, and AI data platform company | Technology |
| Microsoft Corporation | Cloud, productivity software, operating systems, gaming, and AI platforms | Technology |
| Apple Inc. | Consumer devices, software, services, and digital ecosystem company | Technology |
| NVIDIA Corporation | Semiconductor company focused on GPUs, accelerated computing, and AI infrastructure | Technology |
All correctly identified as Technology companies.
For the first time, AI stopped feeling theoretical and started feeling useful.
The Question That Taught Me More – Trust But Verify
Encouraged by the first result, I decided to ask a slightly more interesting question:
Which investor owns the most shares?
This time Oracle generated a much more sophisticated query. It joined investors, accounts, and holdings. It aggregated shares. It ranked the results. While the generated SQL looked reasonable, the result was not what I expected, which immediately triggered the validation process every DBA is familiar with.
As I reviewed the generated SQL, I found myself doing exactly what I would do when reviewing SQL written by another developer.
I wasn’t focused on the answer.
I was focused on the query.
- Are the joins correct?
- Is the aggregation correct?
- Does the SQL truly answer the question being asked?
And that’s when I realized something important. AI wasn’t replacing my database knowledge.
Even more interestingly, while the generated SQL looked very reasonable, the final execution did not return the expected result.
That turned out to be one of the most valuable lessons of the exercise.
The goal isn’t blind trust. The goal is understanding and validation. The AI generated a first draft. The DBA still had to review and verify the outcome.
Why SQL Isn’t Going Away
One fear I hear often is that AI will replace SQL. I do not see it that way.
SQL remains the foundation of how structured data is retrieved, and structured data isn’t going away anytime soon. What is changing is that AI is giving us new ways to access not only relational data, but also JSON documents, text, images, graphs, and other forms of enterprise information using natural language.
Instead of expressing intent through SQL syntax, users can increasingly express intent through natural language.
The optimizer still matters. Indexes still matter. Data modeling still matters. Performance tuning still matters.
The Real Lesson
Looking back, I think I started in exactly the right place.
Not with agents. Not with vector search. Not with machine learning. I started with a question.
Actually, I started with two questions.
- One demonstrated that Oracle could translate business language into SQL.
- The other demonstrated that my DBA expertise was still required to validate the result.
Both lessons were valuable.
And both reinforced a simple idea:
The first step into AI doesn’t have to be complicated.
It can start with something as simple as asking the database a question.
Where Should We Go Next?
One thing I learned while preparing this blog is that understanding a capability and implementing a capability are two very different things.
Asking the question turned out to be the easy part.
Getting Select AI configured involved profiles, credentials, model providers, permissions, and a few lessons learned along the way. The implementation journey was more involved than I initially expected, and I suspect many DBAs exploring AI for the first time will have a similar experience.
That implementation journey could easily become a blog of its own.
Before I decide where to go next, I’d love to hear from you.
Would you find value in a detailed, step-by-step walkthrough of enabling Select AI in Oracle Autonomous AI Database?
Or would you prefer that I continue the learning journey and focus on the next conceptual step in understanding how AI interacts with enterprise data?
Let me know in the comments.
The direction of this series will be shaped by the questions and interests of the people following along.
Sushil Motwani 
Leave a comment