Kafka 4.0 Client Compatibility: Which Clients Break Under KIP-896

The short answer

Apache Kafka 4.0 removed old protocol API versions. KIP-896 set the baseline at Kafka 2.1, released in November 2018: brokers keep the newest API version that 2.1 supported plus everything added since, and drop the older ones. Clients older than 2.1 can no longer talk to a 4.0 broker. The change works in both directions. Brokers must be 2.1 or newer before Java clients, including Kafka Streams and Kafka Connect, are upgraded to 4.0, and clients must be 2.1 or newer before brokers are upgraded.

Most Java estates already meet that. The risk sits in old non-Java client applications, forgotten batch jobs and vendor products that embed an old client library.

What KIP-896 removed

Kafka 3.7 started to deprecate these API versions, and 4.0 removed them. KIP-896 lists the removed API versions in full. The ones most likely to matter:

• Produce v0 to v2. This affects old librdkafka builds in particular, which send the oldest record format unless Produce v3 is available.
• Fetch v0 to v3. This hits old kafka-python releases.
• ListOffsets v0.
• The unversioned SASL protocol that predates the SaslHandshake request.
• JoinGroup v0 and v1, the request a consumer group member sends to join its group. These were removed in 4.0.0 and restored in 4.0.1 and 4.1.0 after a librdkafka Kerberos issue (KAFKA-19444). Run 4.0.1 or later rather than 4.0.0.

Metadata requests lost no versions, because every supported client already uses v4 or later.

Which Kafka clients are compatible with Kafka 4.0 brokers?

For Java clients, including the producer, consumer and admin client, the answer is simple: Apache Kafka client 2.1 or newer. KIP-896 also gives the first compatible release of the common non-Java clients:

librdkafka matters more than its name suggests, because confluent-kafka-python, the .NET and Go clients, node-rdkafka and rdkafka-ruby all inherit its protocol support. Sarama needs extra care: it does not negotiate API versions automatically, so the version set in its configuration decides which requests it sends.

How to check client compatibility before you upgrade

Apache Kafka 3.7 added the detection you need. Each broker exposes a metric that counts requests using API versions due for removal:

kafka.network:type=RequestMetrics,name=DeprecatedRequestsPerSec,request=(api-name),version=(api-version),clientSoftwareName=(client-software-name),clientSoftwareVersion=(client-software-version)

If it reads zero on every broker over a full business cycle, including month-end jobs, the upgrade will not break a client on protocol grounds. The request log also gains a requestApiVersionDeprecated field, which ties each deprecated request to a client ID and address.

For a wider inventory, the per-connection metric from KIP-511 records the software name and version that clients report in their ApiVersions request:

kafka.server:type=socket-server-metrics,clientSoftwareName=apache-kafka-java,clientSoftwareVersion=2.4.0,listener=PLAINTEXT,networkProcessor=1

Clients built before these fields existed do not report a name or version, so treat an empty value as a lead to investigate, not a pass.

The Java and ZooKeeper changes in the same release

• Java 11 for clients. The minimum Java version for clients and Kafka Streams rose from Java 8 to Java 11.
• Java 17 for brokers. Brokers, Kafka Connect and the command-line tools require Java 17.
• KRaft only. ZooKeeper mode was removed. A broker upgrade to 4.0 needs KRaft mode with software and metadata versions of at least 3.3.x, so ZooKeeper clusters migrate on 3.x first. Our ZooKeeper to KRaft migration runbook covers that step.

The new consumer rebalance protocol from KIP-848 also became generally available in 4.0, and Log4j was replaced by Log4j2 for broker logging.

When clients cannot move in time

Sometimes the old client is inside a product you do not control, and the broker upgrade has to wait for the vendor. The broker stays on 3.9, which the community will not patch indefinitely. OSSeva provides extended support for Kafka 3.x, with backported CVE fixes for brokers and ZooKeeper, so the client inventory can be cleared on your schedule. See Kafka support for the versions covered.

Frequently asked questions

Is Kafka 4.0 released?

Yes. Apache Kafka 4.0.0 was released on 18 March 2025, and the 4.1 and 4.2 lines have followed.

Will a Kafka 3.x Java client work with a 4.0 broker?

Yes. Any Java client from 2.1 onwards works with a 4.0 broker. Upgrading the client itself to 4.0 requires Java 11.

Can a Kafka 4.0 client connect to an old broker?

Only if the broker is 2.1 or newer. A 4.0 Java client cannot talk to a 2.0 or older broker.

Is there a Kafka compatibility matrix?

The Apache Kafka documentation publishes client and broker compatibility notes with each release, and KIP-896 lists every API version removed in 4.0. After 4.0 the matrix reduces to one rule: both sides must be 2.1 or newer.

Does Kafka 4.0 break Kafka Streams applications?

Not on protocol grounds if the brokers are 2.1 or newer. Streams applications do need Java 11 once they move to the 4.0 client libraries.