Redpanda Connect v4.112.0 - Incremental CDC Snapshots and Metric Fixes

Redpanda Connect v4.112.0 shipped on October 2, 2026. The headline change is incremental snapshot support for the postgres_cdc input, which removes the need to block the stream or restart from the beginning of a table during backfills.

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

For operators running change data capture pipelines, this release is mostly about reducing the cost of snapshots and closing data loss gaps in the Oracle and Cloud Spanner CDC inputs. There is also a metrics fix that will matter to anyone running mixed fleets of Connect instances.

The postgres_cdc input can now backfill tables in chunks while replication keeps running. Previously, enabling a snapshot meant either blocking the stream until the snapshot finished or restarting the connector from the beginning of the table. Both options are painful with large tables or tight replication budgets.

The change is in PR #4811. If you run Postgres CDC against tables in the hundreds of gigabytes, this is the change worth testing in staging first.

Two separate changes landed for oracledb_cdc.

First, the window strategy now uses a log_count based algorithm to improve change capture efficiency (PR #4864).

Second, the connector no longer loses LOB updates when a transaction contains only LOB events with no DML events. The fix tracks LOB event SCNs and holds the commit checkpoint until all open LOB transactions complete (PR #4902). If you capture from tables with BLOB or CLOB columns, this closes a real data loss case.

gcp_spanner_cdc used to generate new UUID based metadata index names on every connector restart. Each restart burned indexes against the 128 index per table limit in Cloud Spanner, so a connector restarted enough times would eventually fail on index creation.

The fix derives index names deterministically from a hash instead of generating fresh UUIDs (PR #4830). Restarts are now idempotent with respect to metadata indexes. If you already burnt indexes on restarts, note that the existing leaked indexes are not automatically cleaned up by this fix.

The Prometheus metrics output had a suffix problem: histogram timing metrics were exported with an _ns suffix instead of _seconds. When a fleet had mixed use_histogram_timing settings, remote write targets rejected the batches outright (PR #4546). Dashboards and alerting rules built on these metrics should be checked after upgrading, since the suffix changes again.

On the Iceberg output, table creation and schema evolution previously failed on nanosecond timestamp columns. The connector now validates the schema up front and rejects unsupported nanosecond timestamp types before attempting to create or modify tables (PR #4853). That turns a mid pipeline failure into an explicit configuration error, which is the better failure mode.

This is the one item to watch closely. The Kafka input no longer applies the fixed ID schema registry workaround for Redpanda versions before 25.3. It now relies on native IMPORT mode support, and when translate_ids is false the destination registry must be in IMPORT mode (PR #4843).

If you are connecting to a Redpanda registry older than 25.3, upgrade the registry before upgrading Connect, or you will need to keep an older Connect version in place for that pipeline.

Nothing in the notes is labeled breaking beyond the schema registry change above. The two things to verify on upgrade:

  • Destination registries not in IMPORT mode when translate_ids is false.
  • Prometheus dashboards keyed on the _ns histogram suffix, which is now _seconds.