Apache Kafka 4.3.0 landed on June 1, 2026, in a release announcement penned by Mickael Maison and published on the Confluent blog. The release is the third minor version since the project cut over to KRaft as the sole metadata quorum in Kafka 4.0, and it represents the point at which most production operators can comfortably retire their Zookeeper based clusters without holding their breath through the migration.
The headline feature is the hardening of Queues for Kafka, the KIP-932 work that went GA in Kafka 4.2 earlier this spring. Queues introduce share groups, a new consumer abstraction that lets multiple consumers cooperatively process messages from the same partition without the strict ordering guarantees of traditional consumer groups. The original 4.2 implementation worked but had rough edges around rebalancing and lag observability, both of which are addressed in 4.3. Share group coordinators now expose per consumer lag metrics through the standard JMX interface, and the rebalance protocol has been tightened to avoid the duplicate delivery scenarios that early adopters reported on the Kafka users list.
Tiered storage, the feature that lets brokers offload older log segments to S3 or equivalent object storage, also gets significant attention. The 4.3 release introduces a pluggable remote storage manager API that lets cloud providers and storage vendors ship their own implementations without forking the broker. Confluent has signalled that its managed tiered storage will adopt the new API in the next Confluent Cloud refresh, and AWS MSK is expected to follow. For operators, the practical effect is that retention windows can be extended from days to months without the per broker disk cost that used to make long retention prohibitive.
KRaft itself gets several quality of life improvements. Controller failover times have been reduced by roughly forty percent in the project's published benchmarks, and the metadata snapshot format has been compacted to reduce the memory footprint of large clusters. The project has also clarified the deprecation timeline for the remaining Zookeeper migration tooling, with most of it scheduled for removal in Kafka 5.0 next year.
For our streaming platform at Carrefour, the upgrade path looks clean. We have been running Kafka 4.2 in production since April for our order events backbone and have been waiting for the Queues observability fixes before migrating our background job processing workloads off RabbitMQ. The 4.3 release lands exactly the metrics we asked for through the share group coordinator, and we expect to start the migration in the second half of this quarter.
The wider industry context matters too. Confluent's parallel push around its MCP server and Agent Skills means that Kafka is being repositioned as the substrate for agentic systems, not just streaming analytics. The combination of native queue semantics, mature tiered storage and a coherent agent integration story makes Kafka a credible alternative to both AWS SQS plus Kinesis bundles and to the newer entrants like Redpanda and WarpStream. For teams choosing a streaming platform today, the calculus has shifted decisively toward open Kafka with a managed control plane.
There are still gaps. Geo replication via MirrorMaker 2 remains operationally heavy, and the project has not yet committed to a successor design despite ongoing discussion in the KIP queue. Schema management is still effectively delegated to the Schema Registry, which is not part of the Apache project. And the broker startup time on large clusters, while improved in 4.3, is still measured in minutes rather than seconds.
Operators planning the upgrade should pay particular attention to the share group coordinator configuration, which has new defaults in 4.3 that may not match what was tuned manually under 4.2. The release notes call out a small number of breaking changes in the admin client, primarily around the new metrics surface, which will require coordinated upgrades of any tooling that reads broker JMX. Otherwise the upgrade is a standard rolling restart, and the project's testing matrix covers all supported client versions back to 3.6.
There is also a noteworthy security improvement that did not make the headline list. The 4.3 release expands the OAuth bearer token authentication mechanism to support client credentials grant out of the box, which simplifies broker to broker authentication in clusters that already use an enterprise identity provider. For organisations like ours that have standardised on Azure Entra ID for service account issuance, this removes an entire class of custom callback handlers that we previously had to maintain in house.
Finally, the release timing matters for budget planning. Tiered storage adoption typically results in a meaningful shift of cost from compute and local disk toward object storage, and the cost curve only becomes favourable above a certain retention threshold. With the 4.3 hardening and the new pluggable remote storage manager API, we expect to see managed Kafka offerings on AWS, Azure and Google Cloud all reduce their tiered storage premiums over the next two quarters as the operational risk drops. Teams evaluating Kafka against alternatives like Pulsar or Redpanda should refresh their total cost models against the new pricing once the providers publish updates.
