Oracle to BigQuery: Iceberg Lakehouse vs GoldenGate CDC vs Query Federation

On this page

1. 01 · Three Ways to Put Oracle Data in Front of BigQuery
2. 02 · The Architecture at a Glance
3. 03 · Option 1: The Bi-directional Iceberg Lakehouse
4. 04 · Option 2: OCI GoldenGate Change Data Capture
5. 05 · Option 3: BigQuery Query Federation with EXTERNAL_QUERY
6. 06 · Head-to-Head: Freshness, Impact, Copies and Cost
7. 07 · Choosing an Option: A Decision Guide
8. 08 · When to Combine Options
9. 09 · Key Takeaways
10. 10 · Frequently Asked Questions

01 · Three Ways to Put Oracle Data in Front of BigQuery

Oracle AI World, Las Vegas · Google Cloud blog, 28 October 2026

Same goal, three very different mechanisms.

Most enterprises that run Oracle on Google Cloud want the same thing: the transactional truth inside Oracle, and the analytics and AI reach of BigQuery and Gemini, without fragile ETL in between. Google's announcement for Oracle AI World frames this as breaking down "traditional data silos", and it lists three data unification options for Oracle AI Database@Google Cloud. One shares the storage itself. One streams every change. One leaves the data where it is and queries it on demand.

Because the three options have different statuses, costs and side effects, picking one is an architecture decision, not a checkbox. A shared lakehouse changes where tables live. Change data capture creates and maintains a second copy. Federation adds query load to the source database. This post walks through each mechanism at a high level, compares them using only what Google has published, and ends with a decision flow and patterns for combining them.

02 · The Architecture at a Glance

Answer: All three options connect Oracle AI Database@Google Cloud to BigQuery inside Google Cloud, but at different layers: the lakehouse shares Iceberg table files through a REST catalog, GoldenGate reads redo logs and writes into BigQuery managed tables, and federation sends SQL from BigQuery to Oracle through the BigQuery Connection API.

Recall the deployment model: Exadata, Exascale and Autonomous AI Database run in Google Cloud regions on Oracle-operated Exadata, with client subnets in a customer VPC. Oracle and BigQuery therefore sit in the same Google Cloud region, which is what makes all three options practical.

The figure below puts the three paths on one page. Read it row by row. The top row is the shared lakehouse, where Oracle, BigQuery and Managed Spark all point at the same Iceberg tables in Cloud Storage. The middle row is the CDC pipeline, flowing one way from Oracle redo logs to BigQuery managed tables. The bottom row is federation, where BigQuery reaches into Oracle and pulls back live results.

The colours tell the story. Black two-way arrows mean shared storage that every engine can read and write. Purple dashed arrows mean a one-way change stream that produces a second copy. Blue arrows mean a query that travels to Oracle and returns results, with no persistent copy.

03 · Option 1: The Bi-directional Iceberg Lakehouse

Answer: Oracle Access to Google Cloud borderless Lakehouse, in Preview with sign-up, lets Oracle Autonomous AI Database and Google's borderless Lakehouse (BigQuery and Managed Spark) query and write the same Apache Iceberg tables in Google Cloud Storage. It uses a Lakehouse runtime REST catalog, integrated into Oracle through DBMS_CATALOG, so there is no ETL and no replication.

What Apache Iceberg is, briefly

Apache Iceberg is an open table format. Data lives as ordinary files in object storage, and Iceberg adds a layer of metadata that describes which files make up a table, its schema and its snapshots. Any engine that understands Iceberg can treat those files as a proper table, with consistent reads and controlled writes. The table is not owned by one engine, so several engines can share it.

The REST catalog and DBMS_CATALOG

Engines still need to agree on where each table's current metadata is. That is the job of a catalog. Iceberg defines a REST catalog interface, a standard way for engines to look up and update table metadata over HTTP. In this option, Google's Lakehouse runtime provides that REST catalog, and Oracle connects to it through DBMS_CATALOG, an Oracle package that integrates external catalogs into the database. Once connected, Oracle Autonomous AI Database can see the shared Iceberg tables and run queries and DML against them, while BigQuery and Managed Spark do the same from their side.

This option builds on an earlier step. Earlier in 2026, Google's borderless Lakehouse could already read Iceberg tables created by Oracle AI Lakehouse, wherever those tables lived, in any public cloud or on premises. The new Preview makes it two-way, and both sides can write.

Google lists this option as real-time shared storage with zero copy, zero OLTP impact and a best fit for multi-cloud open interoperability. Keep in mind that shared Iceberg tables suit analytical data products; your core OLTP tables still live in Oracle's own storage.

04 · Option 2: OCI GoldenGate Change Data Capture

Answer: A native OCI GoldenGate integration extracts change data capture events from Oracle redo logs, without touching table blocks or adding transactional overhead, and streams them across Google Cloud private networks into BigQuery managed tables through the Storage Write API. Google states sub-second freshness and zero OLTP impact.

Change data capture, or CDC, means capturing each insert, update and delete as it happens and applying it somewhere else. OCI GoldenGate does this by reading the database's redo logs, the record Oracle already writes for every committed change. Because it reads the log rather than querying tables, the production workload does not pay for it in extra reads or locks. The changes travel over Google Cloud private networks and land in BigQuery managed tables through the Storage Write API, BigQuery's interface for streaming rows in.

The result is a continuously updated copy of selected Oracle tables in BigQuery, fresh to under a second. Google positions it as the feed for Gemini, feature stores and live BI, and notes that the same mechanism streamlines on-premises migrations to Oracle AI Database@Google Cloud. The announcement does not give this option a GA or Preview label; it describes it as an integration using OCI GoldenGate. Post 5 in this series covers the CDC pipeline in depth.

05 · Option 3: BigQuery Query Federation with EXTERNAL_QUERY

Answer: BigQuery query federation, in Preview through your account team, uses the EXTERNAL_QUERY function to run native Oracle SQL from BigQuery queries, dashboards and pipelines through the BigQuery Connection API. Data stays in Oracle, so it is zero copy, and results are live, but the load on Oracle depends on the queries you send.

Federation takes the opposite approach to CDC. Nothing is copied ahead of time. When a BigQuery user, dashboard or pipeline needs Oracle data, BigQuery passes a native Oracle SQL statement to the database through a connection defined with the BigQuery Connection API. Oracle runs the statement, and the result set comes back into the BigQuery query, where it can be joined with petabyte-scale BigQuery data.

At a high level, EXTERNAL_QUERY is a function you call inside BigQuery SQL that names a connection and carries the Oracle SQL text to run. Google has not published Oracle-specific syntax details in the announcement, so we will not invent them here; the BigQuery federated query documentation and your account team are the sources to use during the Preview.

The cost of "live in place"

Google lists freshness as on demand and OLTP impact as variable, query-dependent. That is the honest trade-off. A narrow lookup by primary key is cheap for Oracle. A wide scan or a heavy aggregation is real work on the production database, and it runs every time the dashboard refreshes. Federation lowers total cost of ownership by avoiding copies and pipelines, but you pay in source load, so it suits targeted, occasional or intraday queries rather than constant bulk scans.

06 · Head-to-Head: Freshness, Impact, Copies and Cost

Answer: The lakehouse shares one copy that every engine can read and write; CDC keeps a sub-second replica in BigQuery with zero OLTP impact; federation keeps zero copies and is always live, but adds query-dependent load to Oracle. Two of the three are in Preview.

The table below uses only the attributes and status labels Google published. Where Google gave no detail, the cell says so.

The panels below show the same comparison as three cards for steering-group slides.

Look across the "Data copies" and "OLTP impact" rows together. The lakehouse and federation both avoid copies, but only the lakehouse also avoids load on Oracle. CDC accepts one managed copy in exchange for zero load and the fastest predictable freshness in BigQuery.

Thinking about cost and TCO

Google has not published prices for these options in the announcement, and we will not estimate them. Compare the shape of the cost instead. The lakehouse removes ETL jobs and duplicate storage, but you govern shared tables in Cloud Storage. CDC adds a GoldenGate service and BigQuery storage for the replica, and replaces batch pipelines. Federation avoids both pipeline and copy, which is why Google says it lowers TCO, but each query consumes Oracle capacity sized for OLTP. Buying through Google Cloud Marketplace lets you apply existing Google Cloud commitments and unified billing to the Oracle side.

07 · Choosing an Option: A Decision Guide

Answer: Ask three questions in order: do several engines need to write the same tables (lakehouse), does BigQuery need every change within a second (CDC), or is it an occasional live query where no copy is wanted (federation). If the answers are mixed, combine options.

The flow below turns the comparison into three questions. Start at the top. Each "Yes" leads to the option that best fits that need; each "No" moves you down to the next question. Remember to factor in status: two of the outcomes are Preview features, so a production design today should either plan for the Preview to mature or have a fallback.

The order of the questions matters. Shared writes are the rarest and most specific requirement, so it goes first. Sub-second, continuous freshness is next because it rules out federation for heavy dashboards. Federation is the default for anything targeted and occasional.

08 · When to Combine Options

Answer: Combine options when different tables or consumers have different needs: CDC for hot tables that feed AI and dashboards, federation for rare lookups on everything else, and the shared lakehouse for open data products that several engines maintain together.

The options are not exclusive. Roll them out table by table and consumer by consumer, rather than choosing one pattern for the whole database.

1. Inventory consumers. List who needs Oracle data in Google Cloud: Gemini agents, feature pipelines, dashboards, analysts, Spark jobs.
2. Classify each need. For each consumer, note required freshness, query frequency, and whether it must write back.
3. Stream the hot set. Use GoldenGate CDC for the small set of tables that AI and live BI read constantly.
4. Federate the long tail. Use EXTERNAL_QUERY for occasional, targeted queries on tables not worth copying, and watch their load on Oracle.
5. Share open data products. Where Oracle and Spark or BigQuery both maintain a dataset, pilot shared Iceberg tables through the Preview.
6. Review quarterly. If a federated query becomes a constant dashboard, move it to CDC; if a replica is rarely read, consider federation instead.

Pick the pattern per table and per consumer, not per database. The right answer for your order lines is rarely the right answer for your reference data.

09 · Key Takeaways

1. Three options, three mechanisms. Shared Iceberg storage, redo-log CDC and query federation move files, changes and queries respectively.
2. Lakehouse is Preview. Oracle Autonomous AI Database, BigQuery and Managed Spark can query and write shared Iceberg tables through a REST catalog and DBMS_CATALOG.
3. CDC is the freshness and impact winner. OCI GoldenGate gives sub-second data in BigQuery with zero OLTP impact, at the cost of one replica.
4. Federation is zero copy but not zero load. EXTERNAL_QUERY, in Preview, is live in place, and Oracle impact depends on the query.
5. Combine per table. Stream hot tables, federate the long tail and share open data products as lakehouse tables.

10 · Frequently Asked Questions