Introducing Oracle CDC in Redpanda Connect

Teams have a lot of valuable data sitting in their Oracle databases: orders, inventory updates, customer records, and financial transactions. The problem is that it’s all trapped, with no easy way to broadcast changes to the systems that need them.

For years, the answer was Debezium on Kafka Connect. It works, but the operational overhead is real. By the time you have Oracle CDC running in production, you’re maintaining two platforms instead of one. 

We wanted to make that significantly simpler.

Starting with Redpanda Connect v4.83.0, the oracledb_cdc input captures changes directly from Oracle, including: inserts, updates, and deletes. The connector then routes them downstream as structured events. No JVM, no Kafka Connect cluster, no separate workers. Just Redpanda Connect doing what it does best. 

Read on to learn how it works and how you can get started. 

oracledb_cdc requires a Redpanda Enterprise Edition license.

From Oracle to Redpanda in 20 lines of YAML

Here’s a complete pipeline that streams changes from two tables in an Oracle sales schema, then registers each event's schema as Avro, and finally routes them to per-table Redpanda topics. This is the whole config, not an excerpt:

input:
  oracledb_cdc:
    connection_string: oracle://cdc_user:your_password@oracle-db.internal:1521/ORCL
    stream_snapshot: true
    include:
      - SALES\.ORDERS
      - SALES\.ORDER_ITEMS
pipeline:
  processors:
    - schema_registry_encode:
        url: http://schema-registry:8081
        subject: ${! meta("table_name") }
output:
  redpanda:
    seed_brokers:
      - redpanda-broker:9092
    topic: ${! meta("table_name").lowercase() }
    compression: lz4

On first run, the connector takes a consistent snapshot of your tables and emits each existing row as a read event. Once the snapshot finishes, it transitions to streaming mode, tailing Oracle's redo logs from that point forward and picking up insert, update, and delete events as they land. Restarts resume from a checkpointed position stored in Oracle itself, with no external cache required, no re-snapshot, and no gaps.

The include field takes regular expressions, so SALES\.ORDERS matches exactly SALES.ORDERS. Want every table in a schema? One entry: SALES\..*. The table_name metadata field flows through the pipeline, and Bloblang interpolation routes each event to its own topic automatically. One pipeline config, any number of tables.

Schema tracking that doesn't bite you at 3 am

Schema drift is the thing that silently corrupts your downstream data until someone notices a null where they expected a number (usually in production, usually days after the column was added, usually not by you). Most CDC setups leave this problem to you.

The oracledb_cdc connector handles it automatically. It queries Oracle's ALL_TAB_COLUMNS catalog and attaches a full column schema to each message as metadata, with precision-aware NUMBER mapping (integers as int64, decimals as json.Number). The schema_registry_encode processor reads that schema directly, registers it, and encodes the payload as Avro. Your consumers get typed, schema-tracked events from day one. No manual schema management or string columns where you expected numbers.

New columns added to a captured table are detected automatically mid-stream. Dropped columns are reflected after a connector restart. Schema drift is handled, not ignored.

Connecting to regulated environments

Running Oracle in a regulated environment? There’s a good chance that plain-text credentials in a connection string won't pass the security review. Oracle Wallet is the standard answer: a file-based credential store provisioned by the DBA that the client uses instead of a username and password.

Point wallet_path at the directory your DBA provisioned, and the connector handles the rest. SSL is enabled automatically:

input:
  oracledb_cdc:
    connection_string: oracle://host:1521/ORCL
    wallet_path: /opt/oracle/wallet
    wallet_password: "${WALLET_PASSWORD}"  # only needed for ewallet.p12 wallets
    include:
      - SALES\..*

Auto-login wallets (cwallet.sso) do not need a password. If your wallet is a PKCS#12 ewallet.p12, pass the password via wallet_password. It's treated as a secret field and will be redacted from logs and config dumps. The kind of thing that makes security reviewers happy, auditors quiet, and nobody paging you at midnight about a credential in a log file.

One binary. No JVM. No Connect cluster.

Debezium is a solid project. If your team is already running Kafka Connect for other connectors, adding Oracle CDC on top is a reasonable lift. But if you’re not already running Kafka Connect, you’re standing up a significant amount of infrastructure—dedicated workers, connector offsets, a JVM heap to size, its own monitoring surface—for what should be a data pipeline.

Redpanda Connect is a single Go binary. The oracledb_cdc input, schema registration, routing, and output all run in a single process with a single config file. You deploy it the same way you deploy anything else: a container, a systemd unit, a Kubernetes deployment. And because it uses Oracle LogMiner, which ships with Oracle Enterprise Edition, there’s no additional Oracle licensing required. When something goes wrong, the logs are in one place.

Get started

Pull the latest Redpanda Connect and check the full configuration reference for LogMiner tuning, batching options, and everything else. If you’d rather skip the self-managed setup entirely, Redpanda Cloud runs managed pipelines—pay-as-you-go, no infrastructure to operate.

Tell us how you get on in our Community Slack!