As of September 22, 2026, a new stable release of the YugabyteDB gRPC Debezium connector is available:
dz.1.9.5.yb.grpc.2026.1.2.0.2
This release has two particularly useful improvements:
- ● Support for Kafka Connect 4.x
- ● A fix for a very rare connector error-handling condition that could negatively affect a tablet leader
The release updates the connector’s Kafka dependencies from the previous 3.9.x line to Kafka 4.3.1 and changes how Kafka-provided classes are packaged so the connector can run correctly with Kafka Connect 4.x.
What’s New?
Kafka 4.x Support
One of the bigger changes in this release is how the connector interacts with the Kafka Connect runtime.
Earlier connector builds packaged some Kafka classes inside the connector JAR itself. That becomes problematic with Kafka Connect 4.x because the connector can end up carrying Kafka classes that conflict with the classes supplied by the Kafka Connect runtime.
The new release changes those Kafka dependencies so they are provided by the runtime rather than bundled into the connector. The connector is also updated to Kafka 4.3.1.
The bundled Kafka Connect image was also updated for Kafka 4.x logging, including Log4j2 configuration.
An Important Stability Fix
The release also corrects a rare CDC error-handling condition.
The connector communicates with YugabyteDB tablets using GetChanges requests. Previously, one particular INVALID_REQUEST response could be interpreted as though the tablet had split.
That was not always the correct interpretation.
The connector now treats an actual TABLET_SPLIT response as a tablet split while allowing other errors to follow their appropriate error path. The code change specifically removes INVALID_REQUEST from the tablet-split condition.
The Release
The new connector version is:
- dz.1.9.5.yb.grpc.2026.1.2.0.2
The corresponding GitHub tag is:
- vdz.1.9.5.yb.grpc.2026.1.2.0.2
The release commit and version update are present in the connector repository.
The connector project itself provides the YugabyteDB gRPC source connector for Kafka Connect, and YugabyteDB recommends Kafka/Kafka Connect for production CDC use cases.
Demo: Verify Kafka 4.x Support with Docker
Let’s verify that the new YugabyteDB gRPC connector works with Kafka 4.x.
For this demo:
- ● YugabyteDB 2026.1.2.0 is already running on the Linux host.
- ● Apache Kafka 4.0.2 runs in Docker.
- ● Kafka Connect 4.0.2 runs in Docker.
- ● The exact released connector JAR is downloaded from GitHub.
- ● The demo creates a small CDC table, inserts one row, and consumes the resulting event from Kafka.
The flow looks like this:
yb_grpc CDC
ybserver.public.cdc_demo
Download the Demo
The demo bundle contains:
yb-kafka4-cdc-demo/
├── docker-compose.yml
├── connect-distributed.properties
├── demo.sh
├── cleanup.sh
└── plugins/
Extract it:
unzip yb-kafka4-cdc-demo.zip
cd yb-kafka4-cdc-demo
chmod +x demo.sh cleanup.sh
Run the Demo
That’s the easy part:
./demo.sh
The script handles everything else.
It:
- ● Downloads
dz.1.9.5.yb.grpc.2026.1.2.0.2 - ● Cleans up any previous demo run
- ● Verifies YugabyteDB
- ● Creates the test table
- ● Creates a
yb_grpcreplication slot - ● Retrieves its YugabyteDB stream ID
- ● Starts Kafka 4.0.2
- ● Starts Kafka Connect 4.0.2
- ● Verifies that the YugabyteDB connector loaded
- ● Registers the connector
- ● Waits for the connector and task to reach
RUNNING - ● Inserts a row into YugabyteDB
- ● Waits for the Kafka topic
- ● Consumes the resulting CDC event
What the Script Creates
The test table is intentionally simple:
CREATE TABLE cdc_demo (
id INT PRIMARY KEY,
message TEXT
);
The CDC stream is created using the yb_grpc replication-slot interface:
SELECT *
FROM pg_create_logical_replication_slot(
'yb_kafka4_demo',
'yb_grpc'
);
The script retrieves the underlying YugabyteDB stream ID from:
SELECT yb_stream_id
FROM pg_replication_slots
WHERE slot_name = 'yb_kafka4_demo'
AND plugin = 'yb_grpc';
That stream ID is then supplied to the connector as database.streamid.
Kafka and Kafka Connect
Docker Compose starts both Kafka and Kafka Connect using:
apache/kafka:4.0.2
Because YugabyteDB is already running on the same Linux host, the demo uses Docker host networking so Kafka Connect can reach:
YSQL 127.0.0.1:5433
YB-Master 127.0.0.1:7100
The exact released connector JAR is mounted into Kafka Connect’s plugin directory.
Successful Run
Here are the important parts from an actual successful run:
==> Verifying YugabyteDB
PostgreSQL 15.12-YB-2026.1.2.0-b0
==> Creating YugabyteDB gRPC CDC stream with yb_grpc
Slot name : yb_kafka4_demo
Stream ID : 68996bd184ba2ab8cc4a39dc098b244b
==> Starting Apache Kafka 4.0.2
waiting for Kafka OK
==> Starting Kafka Connect 4.0.2 with the released YugabyteDB connector JAR
waiting for Kafka Connect OK
Kafka Connect then discovers the new connector:
{
"class": "io.debezium.connector.yugabytedb.YugabyteDBgRPCConnector",
"type": "source",
"version": "dz.1.9.5.yb.grpc.2026.1.2.0.2"
}
The connector and its task both reach RUNNING:
{
"name": "yb-cdc-demo",
"connector": {
"state": "RUNNING"
},
"tasks": [
{
"id": 0,
"state": "RUNNING"
}
],
"type": "source"
}
The script inserts a row:
INSERT INTO cdc_demo
VALUES (1, 'Hello from YugabyteDB CDC');
Kafka creates the topic:
ybserver.public.cdc_demo
The script then consumes one message from that topic.
The full event contains quite a bit of CDC metadata, but these are the important parts:
{
"before": null,
"after": {
"id": {
"value": 1,
"set": true
},
"message": {
"value": "Hello from YugabyteDB CDC",
"set": true
}
},
"source": {
"version": "dz.1.9.5.yb.grpc.2026.1.2.0.2",
"connector": "yugabytedb",
"schema": "public",
"table": "cdc_demo"
},
"op": "c"
}
The two most interesting pieces are:
"version": "dz.1.9.5.yb.grpc.2026.1.2.0.2"
and
"message": "Hello from YugabyteDB CDC"
The first confirms that Kafka Connect is running the new connector release.
The second confirms that the row inserted into YugabyteDB successfully traveled through CDC and reached Kafka.
RUNNING state, captured an INSERT from YugabyteDB, and published the CDC event to Kafka.
dz.1.9.5.yb.grpc.2026.1.2.0.2, confirming that the new release is the one being exercised.
Cleanup
When you’re finished:
./cleanup.sh
The cleanup script:
yb_kafka4_demo
public.cdc_demo
That returns the YugabyteDB environment to its pre-demo state.
What Did We Prove?
For a release focused on Kafka 4.x support, this gives us a very direct end-to-end validation.
Have Fun!
Today we had all the carpet replaced in our new house in Dallas! 🏡 Since I’m still in Pittsburgh, our daughter was there keeping an eye on things while the crew worked.
I asked her to send me a picture of the new carpet.
This is what she sent me. 😂
Technically, she did send me a picture of the carpet project… just not quite the part I had in mind! 😆