Streaming Oracle to BigQuery in Under a Second with OCI GoldenGate

On this page

1. 01 · Why Sub-Second Oracle Data in BigQuery Matters
2. 02 · What Google Said About the Integration
3. 03 · How Log-Based CDC Works
4. 04 · The Pipeline Architecture
5. 05 · Following One Change from Commit to Dashboard
6. 06 · Use Cases: Gemini, Feature Stores, Live BI and Fraud
7. 07 · Batch ETL vs CDC Streaming
8. 08 · Using CDC for On-Premises Migrations
9. 09 · Operating the Pipeline
10. 10 · Key Takeaways
11. 11 · Frequently Asked Questions

01 · Why Sub-Second Oracle Data in BigQuery Matters

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

Yesterday's extract cannot ground today's answer.

An AI agent that tells a customer their order has not shipped, when it shipped ten minutes ago, is worse than no agent at all. The same is true of a fraud model scoring against stale balances, or an operations dashboard that lags the warehouse floor by a night. For years the default way to get Oracle data into an analytics platform was a batch extract, and batch freshness was good enough for monthly reports. It is not good enough for agents, features and live operations.

Google's Oracle AI World announcement lists a native OCI GoldenGate integration as one of three data unification options for Oracle AI Database@Google Cloud. It captures changes from Oracle redo logs and streams them into BigQuery managed tables with sub-second freshness and zero OLTP impact. Post 4 compared it with the Iceberg lakehouse and query federation. This post goes deep on the CDC path alone.

02 · What Google Said About the Integration

Answer: Google describes a native OCI GoldenGate integration that 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 using the Storage Write API, with sub-second freshness and zero OLTP impact.

As with every feature in this series, it helps to separate what was stated from what was not. The announcement does not label this option GA or Preview. It describes it as an integration using OCI GoldenGate, Oracle's managed data replication service. Confirm availability and supported configurations for your region with Oracle or Google before committing a production timeline.

03 · How Log-Based CDC Works

Answer: Every Oracle commit is already written to the redo log for recovery. Log-based CDC reads that record of changes instead of querying the tables, so it sees every insert, update and delete without adding reads, locks or triggers to the production workload.

Oracle protects every transaction by writing a description of the change to the redo log before the commit completes. That log exists so the database can recover after a failure, and it is written whether or not anyone replicates the data. A log-based CDC tool such as GoldenGate reads this stream and turns each record into a change event: which table, which row, what the old and new values were, and when it committed.

Why the OLTP impact is zero

Compare that with the alternatives. A query-based extract has to read table blocks, compete with transactions for I/O and buffer cache, and often runs in a maintenance window to stay out of the way. Trigger-based capture adds work inside every transaction. Log-based capture does neither: the redo is produced by the normal commit path, and GoldenGate reads it after the fact. This is what Google means by extracting events "without touching table blocks or adding transactional overhead", and it is why the option is listed with zero OLTP impact.

Two further properties follow from reading the log. Deletes are captured as clearly as inserts, because they are just another logged change. And intermediate states are visible: if a row changes three times in a minute, the log holds all three changes, while a snapshot extract would see only the last one.

04 · The Pipeline Architecture

Answer: The pipeline runs from the Oracle primary's redo logs, through OCI GoldenGate, over Google Cloud private networks and the BigQuery Storage Write API, into BigQuery managed tables that Gemini, feature stores and dashboards read. An on-premises Oracle source can use the same CDC mechanism to migrate into Oracle AI Database@Google Cloud.

The figure below lays out the components. On the left, the Oracle primary in Oracle AI Database@Google Cloud writes redo as part of every commit. In the middle, OCI GoldenGate reads that redo and turns it into change events. The events travel over private networking, not the public internet, and enter BigQuery through the Storage Write API, BigQuery's high-throughput interface for streaming rows into tables. On the right, consumers read ordinary BigQuery managed tables. Along the bottom, an on-premises Oracle database feeds the same kind of pipeline during a migration.

The purple dashed path is the whole production story: redo to GoldenGate to BigQuery, never touching table blocks. The orange path shows the migration use: changes from an on-premises source keep a new Oracle AI Database@Google Cloud target in step until cutover. Placement details are illustrative.

Why BigQuery managed tables matter

Landing changes in BigQuery managed tables means consumers do not need to know anything about Oracle. Analysts query with BigQuery SQL, BI tools connect as usual, and Gemini or feature pipelines read tables governed by the same BigQuery controls as the rest of your data. The cost is one copy of the replicated tables in BigQuery, which is the trade-off Post 4 discussed against the zero-copy options.

05 · Following One Change from Commit to Dashboard

Answer: A single change moves through six steps: commit, redo, capture, stream, land and use. Google states the end-to-end freshness into BigQuery as under one second; the consumer's own refresh or call timing then determines when a person or model sees it.

It helps to walk one change through the pipeline, because "sub-second" is easy to misread. Imagine a customer updates a delivery address. The application commits the transaction on Oracle, and the change is recorded in redo as part of that commit. GoldenGate reads the redo record, sends the change over the private network through the Storage Write API, and the row becomes visible in a BigQuery managed table. From there, a dashboard or a Gemini agent can see it the next time it queries. The timeline below labels each step qualitatively, because Google has not published timings for the individual steps.

The green span is the part Google commits to: commit to BigQuery in under a second. The grey tail belongs to you. A dashboard that refreshes every five minutes will still show five-minute-old data, so match refresh and caching settings to the freshness you are paying for.

06 · Use Cases: Gemini, Feature Stores, Live BI and Fraud

Answer: Google positions the CDC feed for Gemini grounding, feature stores and live BI. Fraud and risk scoring that evaluates every event fits the same pattern, while one-off lookups on live records are better served by query federation.

A common thread runs through all five rows. The more often a consumer reads the data, the more CDC pays off, because every read lands on BigQuery rather than on the production database. For a query that runs once a week, a continuously maintained copy may be more than you need, and federation or a scheduled job can be the better fit.

07 · Batch ETL vs CDC Streaming

Answer: Batch ETL copies data on a schedule by querying tables, so it is hours old and adds load to the source. CDC streams every committed change from the redo log, so it is sub-second and, per Google, has zero OLTP impact. The trade-off is an always-on pipeline to operate.

Most Oracle estates already have batch jobs that move data into analytics platforms. They are familiar and well understood, which is a real advantage. The figure contrasts a typical nightly batch pattern with the CDC pipeline on the four things that usually decide the question: freshness, source load, change coverage and operations.

The left column is not wrong; it is slow and it competes with OLTP for I/O. The right column removes both problems but replaces scheduled jobs with a pipeline that runs all the time, which changes what your team monitors. The next two sections cover that.

08 · Using CDC for On-Premises Migrations

Answer: The same CDC mechanism streamlines migrations from on-premises Oracle to Oracle AI Database@Google Cloud: load the target, keep it in step with ongoing changes, validate, then cut over with a short switch rather than a long outage.

Google notes that the GoldenGate integration also streamlines on-premises migrations to Oracle AI Database@Google Cloud. The idea is standard for CDC-based migration. Instead of stopping the application for the whole copy, you copy the bulk of the data while the source stays live, then use change capture to apply everything that happened in the meantime and keep applying until you are ready to switch. The outline below is generic; use Oracle's GoldenGate and migration documentation for exact procedures.

1. Prepare the target. Provision Oracle AI Database@Google Cloud and connectivity from your data centre to Google Cloud.
2. Start capture first. Begin capturing changes on the source so nothing committed during the copy is lost.
3. Load the bulk data. Copy the initial data set to the target while the source keeps serving users.
4. Apply and catch up. Apply captured changes until the target is in step with the source.
5. Validate. Compare row counts and key business totals, and test applications against the target.
6. Cut over. Stop writes on the source, let the last changes apply, and switch applications to the target.

Once the database lives in Google Cloud, the same skills and tooling carry straight over to the BigQuery feed, so migration and analytics can share one CDC practice.

09 · Operating the Pipeline

Answer: Run CDC like a production service: plan the initial load, monitor end-to-end lag continuously, and treat schema changes as a coordinated change across Oracle, GoldenGate and BigQuery.

Initial load

CDC moves changes, so every new target table needs a starting copy. Plan how existing rows reach BigQuery and how the change stream picks up from that point without gaps or duplicates. GoldenGate documentation describes the supported approaches for this integration.

Monitoring lag

Sub-second is the design point, not a guarantee under every condition. Large batch transactions, network issues or a paused process can all increase lag. Track the delay between commit time on Oracle and arrival in BigQuery, alert when it crosses a threshold that matters to your consumers, and show freshness on dashboards so users know how current the data is.

Schema changes

Adding a column in Oracle is routine for a DBA, but it affects every downstream table and query. Agree a process: announce the change, confirm how the integration handles the DDL in the documentation, update BigQuery schemas and consumers, and test in a non-production pipeline first.

Change data capture turns your redo log from a recovery mechanism into a real-time data product. Treat it with the same care as the database it comes from.

10 · Key Takeaways

1. Redo, not tables. OCI GoldenGate reads Oracle redo logs without touching table blocks, which is why Google lists zero OLTP impact.
2. Under a second into BigQuery. Changes stream over Google Cloud private networks into managed tables through the Storage Write API.
3. Built for frequent readers. Gemini grounding, feature stores, live BI and event-level fraud scoring benefit most.
4. Migration tool too. The same CDC approach keeps an Oracle AI Database@Google Cloud target in step until cutover.
5. Operate it like production. Plan the initial load, monitor lag and coordinate schema changes; check the docs for status and settings.

11 · Frequently Asked Questions