Last checked and updated on 12 Jun 2026
What Is New in Apache Kafka 4.0
Apache Kafka 4.0 marks a major milestone by fully removing ZooKeeper support, making KRaft the only mode, while introducing the next-generation consumer rebalance protocol, early queue semantics via Share Groups, and several important cleanups.
| Category | Key Changes |
|---|---|
| New Features | KIP-848 Next Generation Consumer Rebalance Protocol (GA), KIP-932 Share Groups / Queues for Kafka (Early Access), KIP-966 Eligible Leader Replicas (Preview), KIP-996 Pre-Vote in KRaft. |
| Improvements | KIP-890 Transactions Server-Side Defense, KIP-1106 duration-based auto.offset.reset, KIP-1102 client rebootstrap on timeout, KIP-1076 application metrics in client monitoring. |
| Kafka Streams | KIP-1104 foreign key extraction from key or value, KIP-1112 ProcessorWrapper, KIP-1065 RETRY option in ProductionExceptionHandler, improved operator metrics. |
| Breaking Changes & Removals | ZooKeeper removed, Java 17 required for brokers/Connect/tools, Java 11 for clients/Streams, old message formats v0/v1 dropped, old protocol API versions below 2.1 removed. |
| CLI & Admin | New kafka-groups.sh tool, enhanced kafka-consumer-groups.sh and kafka-share-groups.sh for new group types. |
KRaft becomes the only deployment mode
Kafka 4.0 completely drops ZooKeeper support, so every cluster now runs exclusively in KRaft mode.
This simplifies deployment, reduces operational complexity, and improves scalability for large clusters.
KIP-996 Pre-Vote further stabilizes KRaft by letting nodes check leadership eligibility before starting an election, cutting down unnecessary leader changes caused by transient network issues.
Next Generation Consumer Rebalance Protocol reaches GA
KIP-848 replaces the old stop-the-world rebalance behavior with a more incremental and cooperative protocol that greatly improves stability and availability during rebalances.
The new protocol is enabled by default on the broker side, but consumers must explicitly opt in by setting group.protocol=consumer.
In practice, this change makes large consumer groups much less disruptive when scaling or recovering from failures.
Share Groups bring queue semantics to Kafka
KIP-932 introduces Share Groups in early access, allowing multiple consumers to cooperatively process records from the same partitions with individual acknowledgments.
This opens the door for classic queue-style workloads (point-to-point messaging) directly on Kafka topics without the strict partitioning constraints of traditional consumer groups.
While still early access, it represents a significant expansion of Kafka's consumption models.
Java version requirements and logging changes
Brokers, Kafka Connect, and tools now require Java 17, while clients and Kafka Streams require Java 11.
Logging has been upgraded from Log4j 1.x to Log4j2 (KIP-653), with a provided migration tool to help convert existing configurations.
Old message formats v0 and v1, along with very old client protocol API versions, have been removed to clean up the codebase.
Kafka Streams and Connect receive targeted enhancements
In Streams, you can now extract foreign keys from either the key or value in KTable joins, wrap processors with custom logic, and use a new RETRY option in the ProductionExceptionHandler.
Connect gains the ability to replicate internal topics via MirrorMaker 2 and an option to disable heartbeat replication in MirrorSourceConnector to avoid duplicates.
Operator metrics in Streams have also been expanded for better visibility into each StreamThread's state.
Improved client resilience and group administration
Clients can now automatically rebootstrap metadata on certain timeouts or error codes (KIP-1102), reducing problems from stale metadata.
A new kafka-groups.sh tool and enhanced consumer/share group CLIs make it easier to list and troubleshoot all group types.
Duration-based offset reset options and better transaction defenses further strengthen client-side reliability.
FAQ
Is ZooKeeper still supported in Kafka 4.0?
No. ZooKeeper support has been completely removed. All clusters must run in KRaft mode.
How do I enable the new rebalance protocol in Kafka 4.0?
The protocol is active on the broker by default. Consumers need to set group.protocol=consumer in their configuration to opt in.
What Java version do I need for Kafka 4.0?
Brokers, Connect, and tools require Java 17. Kafka clients and Streams applications require Java 11 as a minimum.
Is Share Groups production ready in 4.0?
Share Groups (KIP-932) are in early access. They are suitable for experimentation but not yet recommended for production workloads.
Do I need to change anything for upgrades to Kafka 4.0?
Yes. Brokers must be at least 2.1 before upgrading clients to 4.0, and clients must be at least 2.1 before upgrading brokers. Review the upgrade guide carefully due to removed APIs and Java version changes.