Introducing Oracle Enterprise AI Lakehouse: Unifying AI, Data, and Analytics Across Clouds
Getting Hands-On with Oracle's Enterprise AI Lakehouse
Quick DiSCLAIMER
Quick disclaimer before I get into it, because I know someone will ask in the comments: Oracle's actual product name is Autonomous AI Lakehouse. "Enterprise AI Lakehouse" is the phrase a lot of people (including a few folks on my own team) use informally to describe it, because that is exactly the job it is built for — an enterprise-grade lakehouse with AI baked into the engine rather than bolted on top. I will use both terms in this post, but if you go looking for it in Oracle's docs or console, search for "Autonomous AI Lakehouse."
I have spent the better part of the last few weeks poking at this thing on a sandbox tenancy, partly out of curiosity and partly because three separate customers asked me some version of "should we ditch our data lake pipeline and just point everything at the Autonomous Database?" This post is my attempt to answer that in plain DBA language, with diagrams, because I always draw boxes and arrows on a whiteboard before I trust myself to explain an architecture out loud.
01.Why this exists — the problem on the whiteboard
Every shop I have worked in eventually ends up with the same mess: transactional data sitting happily in Oracle, while a separate pile of "everything else" — logs, exports, JSON blobs, partner feeds, ML training sets — lives out in object storage as Parquet or CSV files, wired up with Spark jobs, a catalog service, and a small army of scheduled pipelines to keep it all synchronized. It works, but it is fragile, and every new AI initiative wants a copy of the data moved somewhere else again.
Oracle's pitch with the Autonomous AI Lakehouse is that you should not have to choose between the openness of a data lake and the performance guarantees of a proper database. It takes the Autonomous AI Database — the fully managed, self-patching, self-tuning database that already runs the OLTP and analytics workloads most of us know — and lets it talk directly to Apache Iceberg tables sitting in object storage, on any of the major clouds, without needing to copy the data in first. You query it in place. That is the whole headline.
02.The architecture, boxes and arrows
Here is the diagram I ended up sketching after my third or fourth pass through the documentation. Read it top to bottom: clients and tools at the top, the database engine doing the heavy lifting in the middle, and the actual data — much of which the database does not own — sitting in object storage at the bottom.
The part that actually surprised me is that this is not a bolt-on lakehouse product sitting beside the database. It is positioned as the next generation of the Autonomous Data Warehouse itself — same engine, same autonomous operations you already trust it for (patching, tuning, scaling), just with a wider reach into object storage.
03.What a query actually does under the hood
I like to trace a request end to end before I trust an architecture, so here is roughly what happens when someone fires off a query — whether it is hand-written SQL, a Select AI natural language prompt, or a scheduled Spark job.
Fig. 2 — Life of a query against the lakehouse
Step 3 is the one I would flag to anyone doing capacity planning: because the accelerator and the cache are separate levers, a well-tuned lakehouse workload here behaves a bit like a combination of a serverless query engine and a traditional buffer cache — you get elasticity for the messy first pass and speed for the workload that repeats.
04.The AI layer — where this stops looking like "just a lakehouse"
What separates this from a plain Iceberg-compatible query engine is that the AI tooling lives inside the same database process, not in a separate service you have to wire up.
| Capability | What it actually does |
|---|---|
| Select AI | Translates a plain-English question into SQL and runs it across tables, files, and lakehouse data, without you writing the join logic yourself. |
| Select AI Agent | A framework, running inside the database, for building agents that chain multiple steps — think a data-prep agent or an alerting agent — using PL/SQL tools, REST calls, or MCP servers as building blocks. |
| Data Science Agent | A pre-built agent aimed at data scientists who want to explore a dataset and get a natural-language summary of what is in it before writing a single line of code. |
| Oracle Machine Learning | Trains and scores models in-database, next to the data, instead of exporting a training set somewhere else first. |
| Graph, Spatial, Vector | Relationship analysis, geospatial workloads, and similarity search, all addressable with ordinary SQL against lakehouse data. |
You can bring your own model, too — Oracle lists support for a fairly long roster of LLM and embedding providers (Cohere, OpenAI, Anthropic, Google, Hugging Face, and the cloud-native options from OCI and AWS, among others), governed by the same access controls you already use for the database.
A worked example: asking a question instead of writing a join
Here is roughly the shape of what a Select AI interaction looks like once you have registered an AI profile pointing at your preferred model. This is illustrative, not a copy-paste from any vendor doc — adjust names and profile settings to match your own environment.
-- one-time setup: point Select AI at a model provider and your lakehouse tables
BEGIN
DBMS_CLOUD_AI.CREATE_PROFILE(
profile_name => 'workshop_lakehouse_profile',
attributes => '{"provider": "openai",
"object_list": [{"owner": "ICEBERG_SALES", "name": "orders_2026"},
{"owner": "ICEBERG_SALES", "name": "returns_2026"}]}'
);
END;
/
-- now just ask the question in plain English
SELECT AI 'which product categories had the highest return rate last quarter,
broken down by region'
;Behind the scenes, that single statement triggers the catalog lookup, the accelerator scaling decision, and the SQL generation step from Fig. 2, all without the analyst ever seeing a JOIN clause.
05.Spreading across clouds — the part that actually matters for procurement
The multicloud story is not just marketing copy tacked onto a slide. Oracle Autonomous AI Lakehouse is genuinely offered on OCI, AWS, Microsoft Azure, and Google Cloud, plus Exadata Cloud@Customer for shops that need the hardware on their own floor. The catalog and the query engine are meant to present one logical surface no matter which cloud the actual Iceberg files happen to sit in.
06.DBA reality check — what I'd actually flag to a team evaluating this
- You are not ripping out your data lake. The whole point is that your existing Iceberg tables stay exactly where they are, in whatever object store you already pay for. What changes is the query surface, not the storage footprint.
- Autonomous still means autonomous. Patching, tuning, and scaling of the database side follow the same operational model as Autonomous Data Warehouse today. If your organization already trusts that model, this is an extension of it, not a new thing to learn from scratch.
- Governance rides along. Because Select AI and the agent framework operate under the database's own security and access controls, you are not creating a second set of permissions to audit — a real concern the moment "AI agent" and "production data" show up in the same sentence.
- It is a genuine competitor to Databricks and Snowflake for this workload, not a replacement for either in every scenario. Analysts covering the launch have pointed out, fairly, that prospective adopters will still want to weigh catalog breadth, Iceberg performance under concurrency, and price against what they already run before switching.
- Zero-ETL claims deserve a pilot, not blind faith. The integration with services like Amazon Bedrock is described as zero-ETL, which is a strong claim worth validating against your own data shapes before you commit a migration plan to it.
07.Wrapping up
I went into this expecting another rebrand of Autonomous Data Warehouse with an Iceberg connector bolted on, and came out thinking the catalog-of-catalogs piece is the actual unlock — it is the part that lets a team stop caring which system originally registered a table. Whether that is enough to move a shop off an existing Databricks or Snowflake footprint is going to be a workload-by-workload decision, and I would want to see it under a real concurrent load before signing off on anything. But for teams already living inside the Oracle Autonomous Database world, this closes a gap that used to mean building — and babysitting — a separate pipeline.
Next post, I am planning to actually spin up a sandbox lakehouse against a small Iceberg dataset and time the accelerator's cold-scan behavior myself. If anyone has already done this in production, I would genuinely like to compare notes in the comments.
Comments