Bridging Oracle and Snowflake AI: The Snowflake Openflow Connector for Oracle Is Now Generally Available

Oracle databases power some of the world's most critical enterprise operations, from global supply chains to healthcare to real-time financial trading. With Cortex Code and Openflow, Oracle data is now connected with the rest of your enterprise data in Snowflake, letting you build AI agents with full context in minutes.

Traditionally, data teams could only access Oracle transactional data through batch ETL or complex CDC platforms, leading to delayed insights for operational dashboards. Multi-hop CDC architectures increased complexity, costs and operational risk. Customers wanted to reduce technology overhead and avoid expensive platforms while benefiting from near real-time data and low-latency movement.

Hearing that call, we are thrilled to announce the general availability of the Snowflake Openflow Connector for Oracle, developed in collaboration with Oracle. This is a fully managed, native, agentless integration that streams data directly from your Oracle instance into Snowflake — without requiring customers to manage additional third-party replication infrastructure. The Snowflake Openflow Connector for Oracle is available today in all AWS commercial regions with Bring Your Own Cloud (BYOC) deployments and in AWS and Azure commercial regions with Snowflake deployments

Proven in production: Customer success

We didn't just build this connector to be compatible with Oracle; we designed it to support the scale requirements of large enterprise environments. During our preview phase, customers tested the limits of the architecture, and the results speak for themselves.

Yes Energy delivers near real-time analytics that accelerate energy market decisions

For Yes Energy, a leader in power market data, "fast" wasn't fast enough. The company needed to migrate massive historical data sets to Snowflake to power its analytics. Using the Openflow Connector’s parallelized snapshotting, Yes Energy reported a significant reduction in load times.

The optimization we've seen with this new integration is a game changer for our pipeline. The initial snapshot load performance with this connector is a huge improvement for our core product flow. A table that previously took more than 10 days to load now finishes in just 5 hours and 40 minutes, and we've seen a 130-million-row table drop from 14 hours to just 1.

Dan Goodman

Staff Engineer, Yes Energy

High performance, low impact

The fear of any DBA is that a replication tool will impact the performance of the source database. We designed the Openflow Connector to be a “good citizen” on your network.

Near real-time latency: Changes are captured from Oracle via XStream in near real time and streamed into Snowflake continuously — with data landing in the Snowflake journal table within seconds of the source commit. Combined with minute-level merge cycles, the connector achieved P90 end-to-end latency under 2 minutes. In internal stress tests, this held steady across 600 tables at 15,000 changes per second for 18 hours straight.¹
Minimal source impact: The connector uses Oracle's native XStream API to capture changes directly from the redo log — a log-based approach that avoids querying source tables. In internal HammerDB TPC-C stress tests on Oracle 19c under sustained high-throughput OLTP workloads, enabling change capture added negligible CPU overhead and sub-millisecond impact to transaction commit latency.

Trusted partnership with Oracle

Connecting mission-critical systems requires trust and reliability. The Snowflake Openflow Connector for Oracle is the result of close collaboration between Snowflake and Oracle, designed from the ground up for enterprise workloads. This partnership enables the following benefits:

Native Oracle CDC: The connector natively embeds Oracle’s own change data capture technology — OEM licensed directly from Oracle — to read logical change records (LCRs) from the XStream outbound server in near real time. This leverages Oracle’s XStream-based change data capture technology, which is also used in Oracle’s replication offerings.
Streamlined support model: Customers work with Snowflake as the single point of contact, while an Oracle partner provides direct support for Oracle components when needed. This reduces handoffs and enables coordinated resolution when issues arise.
Backing from two industry leaders: For Snowflake, the connector unlocks a critical enterprise data source for the Snowflake AI Data Cloud. For Oracle, it extends the reach of Oracle Database into modern cloud and AI ecosystems.
Enterprise confidence for AI: Customers get a best‑of‑breed architecture that brings trusted Oracle transactional data into Snowflake in near real time, backed by two vendors jointly committed to long‑term success.

Together, Snowflake and Oracle help customers move from siloed transactional systems to AI‑ready data, without compromising performance or reliability at the source.

Why native matters

Because the connector runs on the Snowflake Openflow framework, it benefits from the same governance controls and elastic compute you expect from the AI Data Cloud:

Agentless architecture: There is no software to install on your Oracle servers. Connectivity can be configured using private networking options such as AWS PrivateLink or Azure Private Link.
Scalability: The connector automatically scales resources to handle spikes in log generation, helping you keep pace during peak trading hours or seasonal events.
Simplified operations: Set up your Openflow Connector for Oracle with Cortex Code in seconds. Manage your replication directly from the Snowflake Openflow control plane and monitor using native Snowflake SQL, alerts or a Streamlit dashboard.

To understand the engineering philosophy behind this architecture and how it fundamentally differs from legacy middleware, read the private preview announcement we co-authored with Oracle.

From connectivity to AI agents — in a single conversation

Setting up Oracle CDC has historically been a multi-day project requiring specialized DBA knowledge such as configuring XStream outbound servers, sizing redo logs, setting supplemental logging, and troubleshooting cryptic ORA- errors. With Cortex Code, Snowflake's AI-powered coding agent, that complexity collapses into a guided, conversational workflow.

Cortex Code ships with a purpose-built Oracle connector skill that understands your architecture. It walks you through XStream prerequisites step by step — generating the exact SQL your DBA needs — verifies the configuration, deploys the connector, validates data flow, and troubleshoots issues if they arise. What used to require a runbook and a support ticket now happens in a single terminal session.

But the real unlock is what happens after the data lands. Because Cortex Code understands both the connectivity layer and the Snowflake AI stack, the same conversation that sets up your Oracle pipeline can immediately build a Cortex Analyst service over the replicated data, create a Snowflake Intelligence agent that reasons over it, or wire up a Streamlit app for real-time monitoring.

Here’s what it looks like in practice:

$ cortex

> I need to replicate our Oracle 19c orders database to Snowflake

  I'll help you set up the Openflow Oracle CDC connector. First, a few
  questions about your environment:

  1. Is this Oracle on-prem, OCI, or AWS RDS?
  2. Do you have an existing Oracle license, or do you need the embedded
     license from Snowflake?

> It's on RDS and we have an independent license. Oracle credentials
  are in our external vault at vault/oracle-prod, Snowflake credentials
  in ~/.snowflake/connections.toml with key at ~/.ssh/sf_rsa_key.p8.
  Use ORACLE_REPLICA database and REPLICATION_WH warehouse.

  Got it — AWS RDS Oracle 19c with BYOL licensing. I've loaded your
  Oracle credentials from the vault and Snowflake connection config.

  Here's the SQL your DBA should run to prepare the Oracle source.
  I'll generate each step:

  -- Step 1: Configure archived redo log retention (RDS Standard)
  BEGIN
    rdsadmin.rdsadmin_util.set_configuration(
      name  => 'archivelog retention hours',
      value => '24');
  END;
  /
  COMMIT;

  -- Step 2: Enable XStream replication and supplemental logging
  ALTER SYSTEM SET enable_goldengate_replication=TRUE SCOPE=BOTH;
  ALTER SYSTEM SET STREAMS_POOL_SIZE = 2560M;
  ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

  -- Step 3: Create XStream administrator (CDB architecture)
  CREATE USER c##xstreamadmin IDENTIFIED BY "****"
    DEFAULT TABLESPACE xstream_adm_tbs
    QUOTA UNLIMITED ON xstream_adm_tbs
    CONTAINER=ALL;

  GRANT CREATE SESSION, SET CONTAINER, EXECUTE ANY PROCEDURE,
    LOGMINING TO c##xstreamadmin CONTAINER=ALL;

  BEGIN DBMS_XSTREAM_AUTH.GRANT_ADMIN_PRIVILEGE(
    grantee => 'c##xstreamadmin',
    privilege_type => 'CAPTURE',
    grant_select_privileges => TRUE,
    container => 'ALL'); END;
  /
  ...

  Shall I generate the connect user, outbound server, and remaining
  steps for your ORDERS schema?

> Yes, tables ORDERS, ORDER_ITEMS, and CUSTOMERS

  Here's your outbound server setup:

  BEGIN
    DBMS_XSTREAM_ADM.CREATE_OUTBOUND(
      server_name  => 'XOUT_ORDERS',
      table_names  => 'ORCL.ECOMMERCE.ORDERS,
                       ORCL.ECOMMERCE.ORDER_ITEMS,
                       ORCL.ECOMMERCE.CUSTOMERS',
      schema_names => NULL);
  END;
  /

  After your DBA runs this, I'll deploy the connector and verify the
  XStream link. Ready?

> DBA ran it. Let's deploy.

  Deploying oracle-independent-license flow... ✓
  Configuring source parameters... ✓
  Verifying XStream connectivity... ✓
    ├─ Capture status: ENABLED
    ├─ LogMiner session: MINING
    └─ XStream state: SENDING CHANGES
  Starting flow... ✓

  Your tables are replicating. ORDERS is in SNAPSHOT_REPLICATION state
  — initial load is in progress. I'll check back when it reaches
  INCREMENTAL_REPLICATION.

  Meanwhile — want me to set up a Cortex Analyst semantic model over
  these tables so your team can query order data in natural language?

Get started today

The Snowflake Openflow Connector for Oracle is now generally available. You can start streaming your mission-critical data directly from the Openflow Connector catalog within Snowsight. To help you hit the ground running:

Check out our technical documentation for deep-dive configuration details and best practices.
See the connector in action in our online demo on YouTube.
Follow this step-by-step setup developer guide.

Let’s securely connect your Oracle data for AI.

¹ Internal benchmark conducted by Snowflake in November 2025 on Oracle 19c with XStream outbound server. Workload: 15,000 changes per second across 600 tables sustained for 18 hours. End-to-end latency measured from source commit to data availability in Snowflake target tables. Results are from controlled test environments and are not guaranteed in production deployments. Actual latency may vary based on workload characteristics, network conditions, Oracle configuration, and Snowflake account settings.