3.3.0.Alpha1 announcement polish

Author: Naros

_posts/2025-08-05-debezium-3-3-alpha1-released.adoc

@@ -7,7 +7,7 @@ author: ccranfor
 extraClasses: release-v2
 ---
 
-Debezium **3.3.0.Alpha1** introduces an exiting wave of innovation, including exactly-once semantics for core connectors and a brand new CockroachDB connector led by the community.
+Debezium **3.3.0.Alpha1** introduces an exciting wave of innovation, including exactly-once semantics for core connectors and a brand new CockroachDB connector led by the community.
 Featuring support for emerging data types, deeper Quarkus integration, and enhanced tooling, this release raises the bar for modern change data capture solutions.
 Ready to see what's new? Let's dive in.
 
@@ -41,7 +41,7 @@ The CockroachDB connector is a new connector, lead by the community in conjuncti
 This connector is built on top of CockroachDB's change-feed subsystem, to capture row-level changes, and emit those as change events.
 
 This new connector requires CockroachDB 25.2+ with the `rangefeed` option enabled and Java 21+.
-This connector is in an incubating state and is under heavy development by the community.
+This connector is currently incubating and is under heavy development by the community.
 
 If you'd like to get started with the connector, you can get the connector with these coordinates:
 
@@ -50,7 +50,7 @@ If you'd like to get started with the connector, you can get the connector with
 <dependency>
   <groupId>io.debezium</groupId>
   <artifactId>debezium-connector-cockroachdb</artifactId>
-  <version>v3.3.0.Alpha1</version>
+  <version>3.3.0.Alpha1</version>
 </dependency>
 ----
 
@@ -61,7 +61,7 @@ The documentation for this connector is still under development, but you can fin
 There has been numerous requests from the community about Debezium with exactly-once semantics support.
 Exactly-once semantics in layman's terms means that an event should only ever be delivered and written to a Kafka topic once, therefore avoiding the possibility of duplicates.
 
-We are pleased to share that Debezium 3.3 introduces support for exactly-once semantics for all core connectors, including MariaDB, MySQL, Oracle, PostgreSQL, and SQL Server (https://issues.redhat.com/browse/DBZ-9177[DBZ-9177]).
+We are pleased to share that Debezium 3.3 introduces support for exactly-once semantics for all core connectors, including MariaDB, MongoDB, MySQL, Oracle, PostgreSQL, and SQL Server (https://issues.redhat.com/browse/DBZ-9177[DBZ-9177]).
 
 === Disabling context headers
 
@@ -72,15 +72,14 @@ Based on community feedback, we have introduced a new configuration option, `ext
 
 === MariaDB 11.7+ vector data type support
 
-MariaDB 11.7 introduced a new data type called `VECTOR(n)`, allowing the storage of values in the relational database as if it were a vector database.
+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.3 introduces MariaDB Vector support for this new data type in both the MariaDB source connector and the JDBC sink connector when writing to a MariaDB target database (https://issues.redhat.com/browse/DBZ-8582[DBZ-8582]).
-The only requirement to get started with the MariaDB vector data type support is to capture or write changes to a MariaDB 11.7 or later database.
+Debezium 3.3 introduces MariaDB vector data type support in the MariaDB source connector and the JDBC sink connector when writing to a MariaDB target database (https://issues.redhat.com/browse/DBZ-8582[DBZ-8582]).
 
 === MariaDB and MySQL schema history improvements
 
-The MariaDB and MySQL schema history topic is used by the connector to store a variety of DDL operations captured from the binary logs, allowing the connector to maintain a relational model of all captured tables.
+The MariaDB and MySQL schema history topic is used by the connector to store a variety of DDL operations captured from the binary logs, allowing the connector to build a relational model from the chronological history of schema changes for tables.
 
 In Debezium 3.3, the schema history topic's filters were updated to avoid storing specific statements in the topic that are not relevant to Debezium's function, such as procedure, function, view, trigger, and grant/revoke statements (https://issues.redhat.com/browse/DBZ-9186[DBZ-9186]).
 
@@ -95,7 +94,7 @@ For existing connectors, only newly captured DDL statements that match the impro
 In Debezium 2.7, we introduced a bug fix that aligned the behavior of `decimal.handling.mode` when using the `double` or `string` modes in the Oracle connector to match other relational connectors.
 This bug fix introduced a change in the event's schema and created numerous problems for those upgrading who were not expecting such changes.
 
-We looked at a variety of options, whether to introduce legacy support via a `CustomConverter` or a `Transformation`, however, after looking at the changes required, we identified that the legacy support needed to be baked into the connector to provide a sufficient solution to the problem facing users who upgraded.
+We looked at a variety of options, whether to introduce legacy support via a `CustomConverter` or a `Transformation`, however, we concluded that the legacy support needed to be baked into the connector to provide a sufficient solution.
 
 In Debezium 3.3, a new configuration property `legacy.decimal.handling.strategy` was added allowing users to restore the use of the broken behavior, where numeric values with zero-scale would not be automatically converted to `double` or `string` and instead would be emitted as integer whole values as long as their length was 18 or less (https://issues.redhat.com/browse/DBZ-9166[DBZ-9166]).
 
@@ -123,7 +122,8 @@ For systems where there is a disproportionately higher volume of changes in non-
 
 === Postgres text-search vector support
 
-In PostgreSQL 13+, full text search data types were added. The `tsvector` data type represents a document in the form optimized for text searches, providing a sorted list of distinct lexemes.
+In PostgreSQL 13+, full text search data types were added.
+The `tsvector` data type represents a document in a form optimized for text searches, providing a sorted list of distinct lexemes.
 
 With Debezium 3.3, you can now capture changes made to columns using the `tsvector` data type (https://issues.redhat.com/browse/DBZ-8470[DBZ-8470]).
 These column types are emitted using the logical type called `io.debezium.data.Tsvector` and is represented as a _string_ data type in the event.
@@ -137,7 +137,7 @@ With Debezium 3.3 (and backported to the upcoming Debezium 3.2.1), the Debezium
 
 [NOTE]
 ====
-Due to the compatibility changes, when using Debezium 3.2.0.Final or earlier, the Quarkus application must be based on 3.22.x or earlier.
+Due to the compatibility changes, when using Debezium 3.2.0.Final or earlier, the Quarkus application must be based on Quarkus 3.22.x or earlier.
 The use of Quarkus 3.24.x or later is only possible when using Debezium 3.2.1 / 3.3.x or later.
 ====
 
@@ -154,22 +154,23 @@ When enabled, the `debezium.sink.eventhubs.hashmessagekeyfunction` can be set to
 
 === Debezium Platform introduces a Smart Editor
 
-Configuring a Debezium connector across runtimes can sometimes be difficult, particularly when different runtimes use different formats, i.e. Kafka Connect with JSON versus Debezium Server with key/value properties files.
-The Debezium Platform also uses its own JSON-based format that differs slightly from Kafka Connect, which adds another layer of complexity when you may be working with connectors across two or more runtimes.
+Managing similar Debezium connectors across different runtimes presents its own unique sets of maintenance challenges since each runtime uses different formats, i.e. Kafka Connect with JSON versus Debezium Server with key/value properties files.
+The Debezium Platform also uses its own JSON-based format that differs slightly from Kafka Connect, which adds another layer of complexity.
 
-To streamline the user experience with Debezium Platform, a new _Smart Editor_ feature is included, which allows you to write or paste configurations from Kafka Connect or Debezium Server, and convert those to the Platform's format, automatically (https://issues.redhat.com/browse/DBZ-8873[DBZ-8873] https://issues.redhat.com/browse/DBZ-8888[DBZ-8888]).
+To streamline the user experience with Debezium Platform, a new _Smart Editor_ feature is available, which allows you to write or paste configurations from Kafka Connect or Debezium Server, and convert those to the Platform's format, automatically (https://issues.redhat.com/browse/DBZ-8873[DBZ-8873] https://issues.redhat.com/browse/DBZ-8888[DBZ-8888]).
 
 === Quarkus extension improvements
 
 One of the most recent additions to Debezium's portfolio is the Debezium Quarkus extension, which enables developers to utilize Debezium's CDC capabilities directly within a Quarkus-based application in either JVM or Native builds.
+We've added several new improvements, so let's cover each of those separately.
 
 ==== Heartbeat listeners
 
-Debezium can be configured with `heartbeat.interval.ms` with a value greater than zero, forcing Debezium to emit a heartbeat event into the event stream.
-Heartbeat events can be used for a variety of reasons, but their main use is to make sure that offsets remain aligned with the current read state on the source database, even during periods of no activity for captured tables.
+Debezium can be configured with `heartbeat.interval.ms` to make Debezium emit a heartbeat event into the event stream periodically.
+Heartbeat events can be used for a variety of reasons, but their main use is to make sure that offsets remain aligned with the current read state on the source database, even during periods of low/no activity for captured tables.
 
-To allow the Quarkus application to perform addition actions when the `heartbeat.interval.ms` expires, the application can be written to observe the CDI event `DebeziumHeartbeat`.
-This allows for application-specific code to be executed on each heartbeat (https://issues.redhat.com/browse/DBZ-8960[DBZ-8960]).
+A Quarkus application using the Debezium extension can also perform additional actions when a heartbeat is emitted by observing the CDI event `DebeziumHeartbeat`.
+This allows for application-specific code to be executed for each heartbeat (https://issues.redhat.com/browse/DBZ-8960[DBZ-8960]).
 
 In the following example, the listener merely writes to the console when a heartbeat is observed.
 
@@ -186,11 +187,11 @@ public class HeartbeatListener {
 ==== Easily implement custom converters
 
 A Debezium `CustomConverter` is a tool that can be used to change how Debezium emits the value for a given column type.
-This can be an extremely powerful tool for consumers that require data in a specific format.
+This can be an extremely powerful for consumers that require data in a specific format.
 
-Within your Quarkus application, you can use the traditional way to define a `CustomConverter` by specifying it as part of the connector configuration in your `application.properties` file; however, Debezium 3.3 now provides an annotation-based approach that simplifies configuration and makes iterative development much easier and faster (https://issues.redhat.com/browse/DBZ-8966[DBZ-8966]).
+Within your Quarkus application, you can use the traditional way to define a `CustomConverter` by specifying it as part of the connector configuration in your `application.properties` file; however, Debezium 3.3 adds a new annotation-based approach that simplifies configuration and makes iterative development much easier and faster (https://issues.redhat.com/browse/DBZ-8966[DBZ-8966]).
 
-As an example, the following showcases defining a converter that takes a given raw field and return's its value always as a _String_-based field in the emitted event.
+As an example, the following showcases defining a converter that takes a given raw field and return's its value converted as a _String_ in the event using the Java `toString()`  function.
 
 [source,java]
 ----
@@ -203,10 +204,10 @@ class RawToStringConverter {
 }
 ----
 
-You may also need to implement custom converter behavior to be selectively applied to certain fields.
-Developers may be inclined to implement this behavior in the custom converter annotated method, and while that's valid, there is another component-driven way you can do this by using a `FieldFilteringStrategy`.
+In addition, custom converters can be selectively applied to fields.
+Developers may be inclined to implement this behavior in the custom converter annotated method, and while that's valid, this can be done in a component-driven way using a `FieldFilteringStrategy`.
 
-As an example, the following showcases the same custom converter, but it now selectively is applied based on the field filtering strategy:
+As an example, the following showcases the same custom converter, but uses the field filtering strategy:
 
 [source,java]
 ----
@@ -249,7 +250,7 @@ class ProductHandler {
 ----
 
 For this to work, a `Deserializer<T>` needs to be implemented to convert the `ChangeEvent` into our target POJO type `Product`.
-The extension provides an implementation to handle this using Jackson.
+The extension provides an implementation to handle this using Jackson, `ObjectMapperDeserializer`.
 
 [source,java]
 ----
@@ -260,17 +261,17 @@ public class ProductDeserializer extends ObjectMapperDeserializer<Product> {
 }
 ----
 
-The remaining step to glue this all together is to define the deserializer in the Quarkus configuration.
+The last step involves defining the deserializing mapping in the Quarkus configuration to glue it all together.
 
 [source,properties]
 ----
 quarkus.debezium.capturing.product.destination=prefix.inventory.products
 quarkus.debezium.capturing.product.deserializer=<the-java-package>.ProductDeserializer
 ----
 
-This configuration tells the extension that when an event is destined for `prefix.inventory.products`, the `product` deserializer should be used.
+The extension will use this configuration to map an event destined for the `prefix.inventory.products` topic to use the `product` deserializer.
 This deserializer is mapped to the `<the-java-package>.ProductDeserializer` class, which uses Jackson to convert the `ChangeEvent` into a `Product` object.
-When the conversion is applied, the `@Capturing` annotated method is called, providing the `Product` object instead of the emitted `ChangeEvent`.
+After the conversion, the `@Capturing` annotated method is called with the `Product` object instead of the emitted `ChangeEvent`.
 
 [id="other-changes"]
 == Other changes