Debezium 3.0 which will debut later this fall will once again shift the Java baseline requirement from Java 11 to 17 to use Debezium. In preparation for Debezium 3 later this year, we are making the shift to a compile-time baseline for Debezium 2.6 and 2.7 to require Java 17 (DBZ-7387).

If you are a Debezium user, and you consume Debezium connectors, this will require no action on your part. You can continue to use Java 11 for now without issue, understanding that Debezium 3 will require Java 17 later this year.

If you are developing Debezium connectors, Java 17 is now baseline to compile the Debezium source. If you have been using Java 17, there should be no action taken on your part. If you previously were using Java 11, you will need to move to Java 17 in order to compile from source.

If you are using the Debezium Quarkus Outbox Extension (not the Outbox SMT), as Quarkus 3.7+ is making the move to Java 17 as their baseline, the Debezium Quarkus Outbox Extension will now require Java 17 as a baseline for both runtime and compile time.

We expect this transition to be mostly seamless for most users as this should have absolutely no impact on the runtime of Debezium’s connectors nor Debezium Server at this time.

If you’re hearing about the Embedded Engine for the first time, Debezium ships with three ways to run Debezium connectors. The most common is to deploy Debezium on Kafka Connect while the second most common is to use Debezium Server, a read-made runtime for Debezium connectors. However, there is a third option called the Embedded Engine, and it is what Debezium uses internally for its test suite, it’s the foundation for Debezium Server, and it’s meant to provide a way to embed Debezium connectors inside your own application. The embedded engine is used by a variety of external contributors and frameworks, most notably Apache Flink heavily relies on the embedded engine for their Debezium based CDC connectors.

One of the biggest and major new features of Debezium 2.6 is the work on the asynchronous embedded engine that we are debuting in this alpha release. This new asynchronous version the foundation for which Debezium Server and the future of embedding Debezium is based. This change focuses on several key goals and initiatives:

What this new asynchronous model does not include or focus on are the following:

For developers who want to get started with the new asynchronous embedded engine, a new package is now included in the debezium-embedded artifact called io.debezium.embedded.async and this package contains all the pertinent components to utilizing this new implementation. The asynchronous model can be constructed in a similar way to the serial version using the builder pattern, shown below.

We encourage everyone to take a look at the new Asynchronous Embedded Engine model, let us know your thoughts and if you spot any bugs or problems. We will be updating the documentation in coming releases to highlight all the benefits and changes, including examples. Until then, you can find all the details in the design document, DDD-7.

Debezium released the new TimezoneConverter in Debezium 2.4, allowing users to target a specific time zone and to convert the outgoing payload time values to that targeted time zone. The original implementation was specifically restricted to allow conversion of values within the before or after parts of the payload; however, thanks to an improvement as a part of DBZ-7022, the converter can now be used to convert other time-based fields in the metadata, such as ts_ms in the source information block.

This change helps to improve lag metric calculations in situations where the JVM running the connector is using a time zone that differs from the database and the calculation of the envelope ts_ms - source ts_ms results in a variance caused by the time zone. By using the TimezoneConverter to convert metadata fields, you can easily calculate the lag between those two fields without the time zone interfering.

The Debezium SQL Server utilizes a common SQL Server stored procedure called fn_cdc_get_all_changes…​ to fetch all the relevant captured changes for a given table. This query performs several unions and only ever returns data from one of the union sub-queries, which can be inefficient.

Debezium 2.6 for SQL Server introduces a new configuration property data.query.mode that can be used to influence which specific method the connector will use to gather the details about table changes (DBZ-7273). The default remains unchanged from older releases, using the value function to delegate to the above aforementioned stored procedure. A new option, called direct, can be used instead to build the query directly within the connector to gather the changes more efficiently.

Debezium supports secure connections; however, MongoDB requires that the key/trust -store configurations be supplied as JVM process arguments, which is less than ideal for environments like the cloud. As a first step toward aligning how secure connection configuration is specified across our connectors, Debezium 2.6 for MongoDB now supports specifying scoped key/trust -store configurations in the connector configuration (DBZ-7379).

The MongoDB connector now includes the following new configuration properties:

All Debezium change events contain a special metadata block called the source information block. This part of the event payload is responsible for providing metadata about the change event, including the unique identifier of the change, the time the change happened, the database and table the change is in reference to, as well as transaction metadata about the transaction that the change participated in.

In Debezium 2.6, the transaction_id field in the source information block will no longer be provided unless the field is populated with a value. This should present no issue for users as this field was only populated when the connector was configured with provide.transaction.metadata set to true (DBZ-7380).

If you have tooling that expects the existence of the source information block’s transaction_id field although its optional, you will need to adjust that behavior as the field will no longer be present unless populated.

The Debezium Server Google PubSub sink adapter has received a small update in Debezium 2.6. If you are streaming changes that have foreign key relationships, you may have wondered whether it was possible to specify an ordering key so that foreign key constraints could be maintained.

Debezium 2.6 introduces a new configurable property for the Google PubSub sink adapter, ordering.key, which allows the sink adapter to use an externally provided ordering key from the connector configuration for the events rather than using the default behavior based on the event’s key (DBZ-7435).

As a small improvement to the Incremental Snapshot process for the Debezium for MongoDB connector, Debezium 2.6 adds support for the UUID data type, allowing this data type to be used within the Incremental Snapshot process like other data types (DBZ-7451).

The MongoDB connector’s event payload can be configured to include the full document that was changed in an update. The connector previously made an opinionated choice about how the full document would be fetched as part of the change stream; however, this behavior was not consistent with our expectations in all use cases.

Debezium 2.6 introduces a new configuration option, capture.mode.full.update.type, allowing the connector to explicitly control how the change stream’s full document lookup should be handled (DBZ-7299). The default value for this option is lookup, meaning that the database will make a separate look-up to fetch the full document. If you are working with MongoDB 6+, you can also elect to use post_image to rely on MongoDB change stream’s post-image support.