Explore two ways to connect Oracle Analytics Cloud to curated lakehouse data and learn when Oracle AI Data Platform compute or Oracle Autonomous AI Lakehouse is the better query path for your workload.
A curated gold dataset is only useful when its intended consumers can query it through an engine that fits the workload. For Oracle Analytics Cloud (OAC), that design choice becomes important when the data lives in Object Storage, is managed through an AI Data Platform catalog, or is represented as open lakehouse tables.
There are two complementary ways to expose that data to OAC. The first uses Oracle AI Data Platform compute, so OAC queries cataloged data through the AI Data Platform connection. The second uses Oracle Autonomous AI Lakehouse, so OAC queries database objects and lakehouse-accessible data through SQL. Neither is a universal replacement for the other. The right choice depends on where the curated data lives, which query engine should execute the work, and whether the workload also needs database-resident data.
This article walks through those choices, the connection setup for each path, and the questions to ask before building the first workbook.
Two query paths, one analytics goal
Both paths let business users create datasets and workbooks in OAC. The difference is the service that resolves the query and the governed objects it exposes.
In the AI Data Platform path, OAC connects to the selected AI Data Platform compute resource and catalog. This is useful when the gold layer is governed and prepared in AI Data Platform and Spark is the intended execution engine. Oracle’s current AI Data Platform documentation describes an OAC native connection flow based on an OCI API key and an Oracle Analytics connection configuration file.
In the Autonomous AI Lakehouse path, OAC connects to the lakehouse as a database source. This is useful when curated data is already represented by database objects, when the analysis needs SQL joins with database-resident data, or when the database/lakehouse query engine is the intended serving layer. Autonomous AI Lakehouse can work with open data in object storage, including Iceberg-based data, while providing SQL access through the database.
A more complete picture of the two paths is reported in the following image.
Path 1: Query an AI Data Platform catalog through Spark
Use this path when the analytics-ready data product is resident in Object Storage and the team wants OAC to work against that Oracle AI Data Platform catalog through the selected compute cluster. It keeps the BI connection close to the Gold Layer data in Object Storage.
Connect OAC to AI Data Platform
To connect Oracle Analytics Cloud (OAC) to Oracle AI Data Platform, follow the steps in Connect to AI Data Platform.
Path 2: Query through Autonomous AI Lakehouse
Use this path when Autonomous AI Lakehouse is the serving layer for the Gold data. For example, OAC might need to
- Query curated database tables stored in Autonomous AI Lakehouse Storage
- Query curated lakehouse-accessible tables in Object Storage
- Execute the joins and aggregations of gold layer table in Autonomous AI Lakehouse Storage and Object Storage
This route isn’t an Object Storage file connection. OAC connects to Autonomous AI Lakehouse; the lakehouse is responsible for resolving the database objects and any configured lakehouse-accessible data. That distinction matters for governance, SQL design, and performance expectations.
Connect OAC to Autonomous AI Lakehouse
To connect Oracle Analytics Cloud (OAC) to Oracle Autonomous AI Lakehouse, follow the steps in Oracle’s connection tutorial.
How the paths behave in a workbook
An OAC report can look identical while the execution path is very different. For an AI Data Platform connection, the query is issued through the selected AI Data Platform compute and catalog. For an Autonomous AI Lakehouse connection, the database/lakehouse layer resolves the query against database-resident and configured lakehouse-accessible data.
The image below shows a single dashboard containing three reports, each built using one of the query strategies described in this article:
- Autonomous AI Lakehouse connection: A report built on Autonomous AI Lakehouse using database-managed tables.
- Autonomous AI Lakehouse connection with Object Storage data: A report built on Autonomous AI Lakehouse that joins lakehouse-accessible data in OCI Object Storage.
- Oracle AI Data Platform connection: A report built on curated data in an AI Data Platform catalog, queried through a Spark compute cluster.
The three approaches described above may exhibit different reporting performance because they use different execution architectures and optimization techniques. Elapsed time and overall performance can also vary based on file format, partitioning, statistics, data volume, cache state, query complexity, service configuration, and concurrent workload.
Choose an OAC query path for your data
| Decision factor | AI Data Platform compute path | Autonomous AI Lakehouse path |
| Primary serving engine | Spark compute is the intended query engine for cataloged AI Data Platform data. | SQL on Autonomous AI Lakehouse is the intended serving layer. |
| Data and model location | Gold data is managed and governed through the AI Data Platform catalog. | Analytics model is based on database objects and/or configured lakehouse-accessible data. |
| Cross-database SQL | Assess whether the required database data is available to the AI Data Platform query path. | A strong fit when the workbook joins lakehouse data with database-resident data. |
| Workload isolation | Plan cluster capacity and isolate BI from engineering or ML work when needed. | Plan database service capacity and workload management for the OAC workload. |
| Operational simplicity Security | Requires API-key and AI Data Platform connection-file setup, plus compute operations. | Uses a native OAC Autonomous AI Lakehouse connection and database access model. |
A practical starting point
Start with the location and ownership of the gold layer. If the data product is curated and served through AI Data Platform, begin with the native AI Data Platform connection and validate Spark capacity for the OAC workload. If the analytical model is centered on Autonomous AI Lakehouse—especially where it combines database-resident and lakehouse-accessible data—begin with the Autonomous AI Lakehouse connection.
Many enterprise architectures will use both patterns for different data products. The goal is not to standardize on one path, but to make the execution engine, governance boundary, and operating model explicit before the dashboard becomes business-critical.
Further reading
Oracle AI Data Platform documentation
Connect Oracle Analytics to AI Data Platform
Create a connection to Oracle Autonomous AI Lakehouse
Oracle Autonomous AI Lakehouse and Apache Iceberg
Call to action
Start with where your curated data lives and which engine should serve your queries. Choose the path that fits those needs, then use the Oracle Analytics documentation to configure a connection and build a test workbook. Check that users can access the required data and validate performance with your own workload before expanding use.