The Debezium team has wrapped up 2025 with a substantial release: Debezium 3.4.0.Final. This version brings a rich collection of new features, performance improvements, and bug fixes designed to make change data capture (CDC) more powerful, flexible, and enterprise-ready. Whether you’re streaming data from relational databases, building cloud-native pipelines with Quarkus, or working with spatial data types, this release has something to offer.
What Makes Debezium 3.4 Stand Out?
Debezium 3.4 is built against Kafka Connect 4.1.1, marking an important milestone for compatibility with the latest Kafka ecosystem. The upgrade addresses a class-loading regression present in earlier Kafka versions, ensuring smoother deployments for teams running modern Kafka infrastructure.
Beyond Kafka compatibility, the release introduces practical tools for handling large-scale environments, improved geometry transformations for spatial data, and expanded support for the Quarkus framework—a popular choice for building cloud-native Java applications.
Breaking Changes to Know Before Upgrading
While minor releases typically maintain backward compatibility, Debezium 3.4 introduces a few changes that warrant attention before upgrading:
| Component | Change | Impact |
|---|---|---|
| IBMi Connector | Default value trimming now removes leading/trailing whitespace from string fields | New trim.non-xml-charsequence.field.mode property available for control |
| Oracle Connector | XDB and XMLParserV2 libraries now included by default | No more manual downloads needed |
| PostgreSQL Connector | PostgreSQL 13 no longer tested or supported | Plan upgrades to PostgreSQL 14+ |
| PostgreSQL | New lsn.flush.mode replaces deprecated flush.lsn.source |
Provides finer control over replication slot LSN flushing |
| SQL Server Connector | Default data.query.mode changed from function to direct |
More efficient query generation for change capture |
If you’re running PostgreSQL 13 in production, note that official support has ended with this release. The Debezium team recommends upgrading to a supported PostgreSQL version to ensure continued compatibility and access to future improvements.
Core Engine Enhancements
Kafka 4.1.1 Support
Debezium 3.4 requires Kafka 4.1.1 if you’re running Kafka 4.1.0. This isn’t just a routine version bump—it’s essential for working around a class-loading regression that affected earlier 4.x releases. Teams already on Kafka 4.1.0 should prioritize this upgrade.
Memory Guards for Large Schemas
One of the most practical additions is a new guardrail system that protects against OutOfMemoryError issues. If you’re working with databases containing hundreds or thousands of tables, you can now set limits on the number of tables a connector can capture. When these limits are exceeded, Debezium can trigger a warning or halt the connector entirely—preventing unexpected crashes in production environments.
OpenLineage Integration Improvements
Data lineage tracking has become increasingly important for compliance and debugging. The OpenLineage integration has been refined so that when disabled via openlineage.integration.enabled=false, Debezium avoids initializing OpenLineage entirely. This reduces overhead and addresses issues related to the Kafka class-loading regression.
Geometry Transformations
Working with spatial data just got easier. Two new Single Message Transformations (SMTs) simplify handling geography and geometry types:
- SwapGeometryCoordinates: Converts between coordinate systems by swapping (longitude, latitude) to (latitude, longitude) or vice versa—useful when migrating data between databases that use different conventions.
- GeometryFormatTransformer: Converts geometry and geography types between Well-Known Binary (WKB) and Extended WKB formats, streamlining integration across different spatial databases.
Timezone Conversion Updates
The ConvertTimezone transformation now supports converting ts_ms, ts_us, and ts_ns fields in the source information block, giving you more flexibility when normalizing timestamps across systems in different time zones.
Connector-Specific Improvements
IBMi Connector
The IBMi connector gains two notable capabilities:
- Incremental Snapshots: On-demand, resumable incremental snapshots allow targeted backfills without pausing the entire pipeline—a significant improvement for operational flexibility.
- Multi-Journal Support: The source block now includes journal receiver metadata (file name, library, timestamp, sequence number), ensuring correct event ordering when multiple journals are assigned to tables.
MongoDB Connector
When MongoDB 6+ emits wallTime in change streams, Debezium now uses it for the ts_ms, ts_us, and ts_ns fields. For older MongoDB versions without wallTime, the connector falls back to clusterTime. This provides more accurate timestamps that better reflect when changes actually occurred.
Oracle Connector
Oracle users benefit from several improvements:
| Feature | Description |
|---|---|
| Improved LogMiner Metrics | CommitThroughput JMX metric now focuses only on commit durations for more accurate throughput measurements |
| New TotalCommitTimeInMilliseconds Metric | Tracks total time spent in the commit loop |
| Mining Range Metrics | New JMX metrics expose LogMiner session boundaries, helping troubleshoot performance issues |
| Subset Database Replication | Oracle 21’s subset replication mode is now recognized as equivalent to minimal supplemental logging |
| Drop Transaction Signal | A new Oracle-specific signal lets you manually discard buffered transactions mid-stream |
| Configurable Performance Options | New properties allow tuning session parameters like hash_area_size and sort_area_size |
SQL Server Connector
- Resumable Incremental Snapshots: If a connector restart occurs during an incremental snapshot, Debezium now correctly resumes rather than failing—a welcome improvement for reliability.
- Multitask Signaling: Deployments capturing multiple databases on a single instance now fully support signals, including snapshot triggers and blocking signals.
Vitess Connector
A new vitess.exclude.keyspace.from.table.name=true option reduces VTGate overhead when streaming from a single keyspace, improving performance for Vitess deployments.
Quarkus Extension: A Game-Changer for Cloud-Native Development
One of the most exciting additions in Debezium 3.4 is the enhanced Quarkus extension with DevService support. This enables developers to spin up Debezium connectors as Quarkus DevServices with minimal configuration.
Supported Databases for DevServices
| Database | DevService Support |
|---|---|
| PostgreSQL | ✓ |
| MongoDB | ✓ |
| MySQL | ✓ |
| MariaDB | ✓ |
| SQL Server | ✓ |
Running Multiple DevServices
Quarkus applications can now run multiple Debezium DevServices simultaneously. This enables event aggregation from different database sources within a single application. You can use annotations like @Engine("default") and @Engine("alternative") to control which service processes each event—providing flexibility for complex microservice architectures.
JDBC Sink Improvements
The JDBC sink connector receives several quality-of-life improvements:
- FieldNameTransformation Fix: The transformation now correctly applies the desired case to all payload fields.
- Geometry Type Support: The sink converts geometry column values to the target database’s desired format automatically.
- Passthrough Collection Naming: A new
PassthroughCollectionNamingStrategyallows using the event topic name directly as the target table name, simplifying transformation pipelines.
Debezium Server Updates
Native OpenLineage Output
Debezium Server can now emit OpenLineage output datasets without requiring a separate transformation. A few configuration properties enable lineage tracking for your connectors, making it easier to maintain data governance in your CDC pipelines.
Dynamic Partition Routing for Azure Event Hubs
A new debezium.sink.eventhubs.dynamicpartitionrouting configuration option allows fine-tuning how keys, partition IDs, or batch indices determine the partition when publishing to Azure Event Hubs. This is particularly useful for optimizing throughput and ensuring proper event ordering.
Notable Bug Fixes
Beyond new features, Debezium 3.4 addresses numerous stability issues:
- Fixed a bug where the DB2 CDC source randomly lost events
- Updated the MongoDB driver to version 5.5.1
- Resolved null pointer exceptions in the Cassandra connector
- Various UI improvements and error-handling fixes across the platform
What’s Coming in Debezium 3.5?
With 3.4 complete, the Debezium team is already looking ahead to Debezium 3.5, scheduled for early 2026. Planned features include:
- Cloud storage sinks and source connectors
- Milvus and Qdrant vector database support for Oracle
- Advanced filtering for the Quarkus extension
- Improved user experience in the web-based management platform
- Multi-threaded single table snapshots
You can follow the evolving roadmap on the official Debezium website to track what’s coming next.
Should You Upgrade?
Debezium 3.4 is a substantial release that addresses real-world pain points for data engineers. If you’re using Kafka 4.1.x, the upgrade is essentially required to avoid the class-loading regression. For everyone else, the new memory guards, improved metrics, and Quarkus enhancements make this release worth considering—especially if you’re running at scale or building cloud-native applications.
Before upgrading, review the breaking changes (particularly if you use PostgreSQL 13 or rely on deprecated configuration properties) and test in a non-production environment. The Debezium team has published detailed migration notes to guide you through the upgrade process.
Sources: