Should I upgrade to Debezium Connector Upgrade Risk now?

Teams already running Debezium need a current decision card on whether newer MySQL and PostgreSQL connector releases can be bumped in place or whether Kafka Connect, SMT, schema-history, or managed-service baseline changes justify a staged migration.

Staged migration first unless you're already self-managed on Java 17+ and near Debezium 3.x baselines; do an in-place bump only when those guardrails are true.

Blockers

Who this is for

Candidates

In-place bump only when you are already on a modern self-managed baseline

As of 2026-04-02, upstream Debezium 3.0.8.Final is built against Kafka Connect 3.9.0, and Debezium 3.0.6 through 3.0.8 state that connectors can resume from the prior position with the same configuration after plugin replacement. That makes an in-place bump plausible only for teams already on a compatible Kafka Connect and Java baseline. However, Red Hat build of Debezium 3.2.6 raises the runtime floor to Java 17 for all connectors, requires Java 21 for Debezium Server, and is built and tested with Apache Kafka 4.0. The same 3.2.6 release also versions the event `source` block and warns that schema-registry users can hit compatibility issues.

When to choose

Use this only if your estate is already self-managed, already standardized on Java 17 or newer, and your Kafka Connect workers are near the Debezium 3.x tested baseline. It is the lowest-friction option when you do not depend on strict schema-registry compatibility and you do not rely on internal schema-history capturing of MySQL `TRUNCATE` or `REPLACE` statements.

Tradeoffs

Fastest path and least operational churn, but only if your platform baseline is already aligned. The risk is hidden breakage outside the connector config itself, especially worker JVM level, schema-registry compatibility, and MySQL schema-history expectations.

Cautions

Red Hat build 3.2.6 says Java 11 workers may silently fail to discover new connectors. It also changes the versioning of the `source` block, which can break schema compatibility checks, and for MySQL it no longer stores `TRUNCATE` and `REPLACE` DDL in internal schema history.

Sources

Staged migration before upgrading when crossing old baselines or managed legacy connectors

As of 2026-04-02, a staged migration is justified when moving from Debezium 1.x or from Confluent Cloud legacy Debezium connectors. Red Hat's Debezium 2.1.3 upgrade notes say upgrading from 1.x requires manual steps, including temporarily carrying both old and new property names, because key settings were renamed: `database.history.*` moved to `schema.history.internal.*`, and `database.server.name` moved to `topic.prefix`. The same 2.1.3 notes also state that PostgreSQL `wal2json` is no longer supported. Separately, Confluent documents that its legacy MySQL and PostgreSQL Debezium source connectors reached end of life on March 31, 2026 and recommends migration to the V2 connectors.

When to choose

Use this when your connectors are still on Debezium 1.x-era configuration, when your PostgreSQL estate still depends on `wal2json`, when your SMT stack still uses removed transforms, or when you are on Confluent Cloud legacy Debezium connectors. This is the safer choice when rollback, dual-running, or config translation is cheaper than discovering breakage during a direct bump.

Tradeoffs

More work up front because you need config translation, environment validation, and often shadow testing. In exchange, you reduce outage risk from connector discovery failures, unsupported PostgreSQL decoding plugins, schema-history property breaks, and managed-connector retirement.

Cautions

Red Hat's 2.5.4 notes say the `ComputePartition` SMT was removed and must be replaced with `PartitionRouting`. Red Hat's 2.1.3 notes also say storage module dependencies changed, metrics exposure changed, and schema-registry users might see compatibility issues from schema-definition changes. As of 2026-04-02, Confluent Cloud legacy Debezium MySQL and PostgreSQL connectors have already reached EOL, so the decision window for staying on them has closed.

Sources

Facts updated: 2026-04-02
Published: 2026-04-03

Related questions

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Should I upgrade to Debezium Connector Upgrade Risk now?"
Missing something? Request coverage