In Debezium 3.2.0.Final, we introduced several new headers to provide context for OpenLineage that are automatically added to every emitted event. Some users reported concerns with these being added with no way to disable them, as some environments had the need to keep event payloads as lean as possible.

Based on community feedback, we have introduced a new configuration option, extended.headers.enabled, that can be set to false, disabling the addition of these context event headers (DBZ-9248).

MariaDB 11.7 introduced the VECTOR(n) data type, allowing the storage of values in the relational database as if it were a vector database. Vector values that are generated by an AI model can be stored and searched in MariaDB using this new data type.

Debezium 3.2 introduces MariaDB vector data type support in the MariaDB source connector and the JDBC sink connector when writing to a MariaDB target database (DBZ-8582).

The Debezium for PostgreSQL pgoutput decoder uses a specific pattern to determine whether a toasted column’s value matches a predefined list of marker objects that indicate the value is absent in the change event. However, this pattern was inefficient when the event payload contained large text or binary data, due to the cost of computing hash values before comparison.

To improve performance, the implementation now uses a direct equality check, avoiding expensive hash computations for large TOAST column payloads (DBZ-9345). This change reduces processing overhead when handling events with sizable text or binary data.

We have introduced a new internal and experimental feature for Oracle LogMiner that leverages a concept called a CTE query, or a Common Table Expression query. A CTE query is a SQL construct that allows for the definition of a temporary, named result set within the execution of another SQL operation, which can be useful for a variety of reasons.

For the Debezium Oracle connector, the new internal.log.mining.use.cte.query feature toggles a special pre-pass that examines all transactions and performs a pre-filter pass (DBZ-9272). This filter pass is designed to only send START, COMMIT, and ROLLBACK events for transactions that actually contain at least one DML operation for a captured table. In other words, if someone performs 100 transactions and only one of those transactions modifies your captured table, then not only do we not receive the DML events for the other 99 transactions, but the transaction markers are also omitted, too.

When using the LogMiner connection adapter in its default configuration, the Debezium Oracle connector buffers transactions in memory. Although the existing NumberOfActiveTransactions JMX metric lets you see how many transactions are currently open, it does not reveal how many individual transaction events are being cached — the primary driver of the connector’s memory usage.

To address this, we have introduced a new JMX metric, NumberOfEventsInBuffer, available when using the buffered LogMiner adapter (DBZ-8991). This metric reports the total number of transaction events currently held in the transaction buffer, giving you deeper visibility into the connector’s in-memory footprint and helping you better monitor and tune performance.

When starting an Oracle LogMiner session, it is possible for an ORA-00310 error to occur if an online redo log transitions to the archive just as the logs are being collected for mining. In previous versions, this situation would typically require the connector to stop and restart, provided that error retries were enabled in the runtime.

For improved performance and resiliency, we have updated the connector to treat ORA-00310 as a log inconsistency condition (DBZ-8870). When this occurs, the connector now regathers the list of logs and revalidates log consistency, rather than immediately propagating the exception to the runtime. This change leverages the existing log consistency retry mechanism, avoiding unnecessary connector restarts.

When the Oracle connector is configured to perform database-level heartbeats using the heartbeat.action.query property, an ORA-02396 exception could occur if a batch of changes takes longer than the session’s allowed idle timeout. In this case, when the next heartbeat query executes, the idle session timeout would cause the connection to fail, resulting in the connector stopping and triggering a restart — an inefficient and unnecessary interruption.

Starting with Debezium 3.2.1, the heartbeat action query handler is now resilient to idle session timeouts. An ORA-02396 exception will no longer cause the connector to stop and rely on the runtime to restart it (DBZ-9280). This enhancement improves connector efficiency and stability in environments where long-running change batches might otherwise trigger timeouts.

Quarkus 3.24 and later now ship with the Hibernate 7+ persistence framework. This Hibernate upgrade introduced a breaking change that affected compatibility with the Debezium Outbox extension when running on Quarkus 3.24 or newer.

Starting with Debezium 3.2.1.Final, the Outbox extension includes the necessary updates to restore compatibility with the latest Quarkus builds (DBZ-9219).