What Is New in Apache Kafka 3.3
Kafka 3.3 brings a host of improvements focused on stability, performance, and developer experience. The key changes are summarized in the table below.
| Category | Key Changes |
|---|---|
| New Features | Kafka Raft (KRaft) consensus mode is production-ready, ZooKeeper is deprecated. New
kafka-metadata-shell CLI tool. |
| Improvements | Enhanced partition reassignment, better log flush behavior, improved metrics, and ZooKeeper session timeouts. |
| Bug Fixes | Numerous fixes for KRaft, consumer group coordination, and transaction handling. |
| Deprecations | ZooKeeper for metadata management is officially deprecated. |
Is KRaft production-ready now?
Yes, the KRaft consensus protocol is now officially production-ready in Apache Kafka 3.3. This is the headline feature, marking the culmination of the multi-year effort to remove the ZooKeeper dependency.
In practice, this means you can now run Kafka clusters without ZooKeeper for metadata management, simplifying deployment and operations. The community considers it stable for production workloads, though many will take a cautious rollout approach.
What tools help with the ZooKeeper migration?
A new CLI tool, kafka-metadata-shell, was introduced to help inspect and debug the metadata state in
KRaft clusters. This is crucial for operators transitioning from ZooKeeper.
You can use it to directly examine the metadata log, query partition states, and understand the internal snapshot files. It fills a gap that existed during the KRaft development cycle, providing much-needed visibility.
How is partition management improved?
The partition reassignment process received significant enhancements. The
kafka-reassign-partitions.sh tool now supports a --verify option and provides more
detailed progress output.
This matters because reassignments are a common but potentially risky operational task. The improved feedback loop makes it easier to track the movement of data and confirm completion without guessing.
Were there any performance tweaks?
Yes, several under-the-hood changes improve performance and stability. The default behavior for log flushing was adjusted to be more efficient, which can reduce I/O pressure.
There are also updates to how ZooKeeper session timeouts are handled, reducing unnecessary churn. These are the kinds of incremental gains that add up to a more robust cluster in high-throughput scenarios.
FAQ
Should I use KRaft for my new production cluster?
Yes, Kafka 3.3 designates KRaft as
production-ready. For new deployments, starting with KRaft mode is now the recommended path to avoid a future
migration from ZooKeeper.
Is ZooKeeper completely removed in 3.3?
No, ZooKeeper is still available but is now formally
deprecated. You can run in ZooKeeper mode, but the focus of all new development is on KRaft.
What is the kafka-metadata-shell tool used for?
It's an interactive CLI for inspecting the
internal metadata state of a KRaft cluster, similar to how you might have used ZooKeeper shell commands before.
It's essential for debugging.
Are there any breaking changes in the client APIs?
No, the client APIs remain compatible. The
changes in 3.3 are largely internal (KRaft) or additive (new tools, options), so upgrading clients should be
straightforward.
How does this release impact Kafka Connect or Streams?
Kafka Connect and Streams benefit from
the overall broker stability but don't have major new features in this release. They are fully compatible with
KRaft-based clusters.