Oracle announced on October 28, 2026 that Oracle AI Lakehouse, part of Autonomous AI Database, now goes further with Apache Iceberg. It can attach to external catalogs, read a wider range of Iceberg tables and write new Iceberg tables from SQL.
For database developers this means Oracle SQL can work on shared lake data without copying it into Oracle tables first. The same data stays open to other engines such as Databricks, Snowflake and AWS Glue.
What Oracle announced
The announcement has four parts. Each one targets a common pain point when a team keeps analytics data in open files on object storage.
- Catalog federation: link Oracle AI Data Catalog or another supported catalog one time and see every table you may use.
- Wider read support: more Iceberg features are understood, so tables created by other engines can be queried.
- Native writes: create Iceberg tables and publish the output of an Oracle SQL query into them.
- Performance work: Iceberg tables are planned by the Oracle optimizer, with caching and scale-out reads for large scans.
How catalog federation works
Iceberg keeps the data as Parquet files in object storage. Metadata files describe the schema, the files and the snapshots, and a catalog tells engines where that metadata lives.
Until now, an Oracle user usually had to define an external table for each Iceberg table. With federation, a single catalog connection can expose hundreds or even thousands of tables across namespaces. New tables show up after a catalog refresh, and defining individual external tables is still possible.
In SQL you point at a shared table with the form namespace.table@catalog. That lets one query join local Oracle tables with Iceberg tables from several catalogs. Oracle's own example mixes Oracle data with tables from Oracle AI Data Catalog, Snowflake Open Catalog and Databricks Unity Catalog.
Access still follows the permissions set on the catalog and on the storage.
Data Studio gives a visual way to browse the connected catalogs and then open SQL Worksheet to run queries.
Reading more Iceberg tables with consistent results
Oracle lists time travel and partition pruning among the supported capabilities. Time travel lets you query an older retained snapshot, chosen by a timestamp or a snapshot ID. Partition pruning uses Iceberg metadata to skip partitions that cannot match your filter.
Oracle also says compatibility depends on which Iceberg features a table uses and on the release, not only on the table format version. Check the documentation before you plan around a specific table.
A notable addition is read consistency. A single statement sees one snapshot. Inside a supported read-only transaction, repeated queries keep seeing the same snapshot, even if another engine publishes a newer one in between.
Writing Iceberg tables from Oracle SQL
You can now create an Iceberg table inside a connected catalog and give it an object storage location. Then you fill it with an INSERT that selects from joined sources, and finish with COMMIT.
The engine writes Parquet files and Iceberg metadata to storage, and the commit publishes a new snapshot through the catalog. Other compatible engines can then query the result. The published table is a new, derived dataset, and neither source is moved.
Oracle's example joins current orders held in Oracle with customer segments held in Iceberg and publishes the outcome as a shared sales table. Write support differs by catalog, storage, authentication and release, so verify your setup first.
Performance features
Oracle describes several layers that reduce the amount of data read from object storage.
- Pruning by partition metadata and by the min/max statistics kept in Iceberg manifests, plus predicate pushdown during scans.
- The optimizer treats Iceberg tables like other tables when planning joins and parallel execution.
- Lake Cache keeps frequently used Iceberg data on Exadata storage for fast repeat reads.
- Data Lake Accelerator adds Oracle-managed I/O and compute for large eligible scans.
- Clustering and compaction, described as being added, to improve file layout and merge small Parquet files.
The performance claims in the post are not benchmark results, and Oracle labels its diagram as illustrative. Test with your own data before you rely on them.
What it means for developers
If your company already runs a lake on Iceberg, this lowers the cost of using Oracle SQL on it. You skip the ETL job that copies lake data into a database just to join it with operational tables.
It also fits a clear split of roles. Keep transactional data with strict constraints and low latency in Oracle tables. Keep large analytical data that several engines share in Iceberg, and publish derived results back to the lake when other teams need them.
Plan carefully for permissions. A federated catalog exposes tables according to catalog and storage grants, so review who can see what before you connect one. Also remember that the feature list varies by catalog, so a Snowflake or Databricks catalog may not support every operation that Oracle's own catalog does.
If you are new to joining remote sources in Oracle, our Oracle external table tutorials explain the older approach that catalog federation partly replaces.
How to get started
Begin with a supported catalog and the storage access it needs. Open Data Studio, pick an Iceberg table you have access to and run a query that joins it with your Oracle data. When you want to publish a result, use the create, insert and commit workflow described above, and confirm the supported configurations in the Oracle documentation first.
Conclusion
Oracle is positioning AI Lakehouse to read and also write shared Iceberg data. The practical gains are fewer copies, one SQL surface across several catalogs and consistent reads. Details such as supported catalogs, write support and performance should be tested in your own environment.
Sources
See my articles more often when you search Google.
