Redpanda Connect v4.113.1 - Oracle CDC Metadata and a SAP HANA Input

Redpanda Connect v4.113.1 was published on October 14, 2026. The headline is a new sap_hana polling input, alongside a set of changes to the oracledb_cdc input that make row level changes easier to identify and faster to read. It is a stable release, not a prerelease.

The full release notes and downloads are on the GitHub release page.

Three of the changes in this release touch oracledb_cdc. Two of them are about metadata, and one is about speed.

The input now exposes rs_id and ssn metadata (#4826). Together they identify a row change inside a transaction. If you build downstream dedup keys or ordering logic from CDC output, these are the fields that were missing.

Those two fields are not always enough. A bulk DELETE can produce many rows where rs_id and ssn are identical. The release adds row_seq metadata to tell those rows apart (#4827). A composite key of all three should now be unique per row change. The notes do not say how row_seq is numbered, so check a real bulk delete in a test environment before you depend on its ordering.

The third change is performance. The input now processes rows in parallel, and the read ahead buffer scales with the prefetch_rows setting (#4941). The notes give no benchmark figures. Parallel processing has a cost: if your pipeline assumed strict row order within a batch, validate that assumption after upgrading. The metadata fields above are the obvious tool for that check.

The new sap_hana input reads from SAP HANA by polling (#4775). It supports four modes: bulk, incrementing, timestamp, and query. It checkpoints progress with a high water mark, and it discovers schema metadata.

This is polling, not log based change capture. That has the usual tradeoffs:

  • Incrementing and timestamp modes need a monotonic column. Rows updated in place without touching that column will be missed.
  • Hard deletes are invisible to a poller. Only a full bulk read or a custom query will notice them.
  • Checkpointing keeps restarts cheap, because the input resumes from the stored high water mark instead of rereading the table.

For teams that need to move HANA data into Kafka or Redpanda topics without running a separate connector framework, this removes a custom step. For teams that need deletes, plan for a different mechanism.

The redpanda_migrator fix is the one most relevant to anyone running a schema registry migration (#4895). Previously, a failure registering a single subject could fail the whole output connect. Now the output tolerates per subject failures. The migration proceeds, and the failed schemas are retried.

The tradeoff is visibility. A migration that starts despite some missing schemas can hide a partial result. Watch your logs for retried subjects, and confirm the target registry contains every subject you expect before cutting consumers over.

The kafka output has a default change as well. The compression field now defaults to snappy, and the docs describe more clearly what happens when the field is unset or when batches are sent uncompressed (#4951). Snappy trades some CPU for smaller payloads. If you had relied on the old behaviour, and your brokers or network are sensitive to either side of that tradeoff, set compression explicitly in your config.

The Prometheus exporter documentation gained guidance on the histogram_timing setting for mixed fleet deployments (#4946). This is documentation only. It matters if you run different versions side by side and see metric conflicts, since the notes describe the setting as the way to prevent them.

There are no breaking changes listed. Two items deserve a check before rollout:

  • The kafka compression default is now snappy. Pin the value in config if you want predictable output across upgrades.
  • The oracledb_cdc input now processes rows in parallel. Verify any ordering assumptions in downstream processors, using the new rs_id, ssn, and row_seq metadata.

The upstream change log has the complete list. Installation steps are in the getting started guide.