Instaclustr for Apache Kafka® and Kafka® Connect 4.3.1 are now generally available

August 06, 2026 | By Varun Ghai

 

We are pleased to announce that Apache Kafka® and Apache Kafka® Connect 4.3.1 are now Generally Available (GA) on the NetApp Instaclustr Managed Platform.

Kafka 4.3.1 is the first release from the 4.3.x line to reach GA on our platform, following 4.2.1. It carries forward the feature set introduced in the upstream 4.3.0 release alongside the stability fixes shipped in 4.3.1, including fixes for incorrect group coordinator error logging following partition leadership changes and Kafka Streams RocksDB native memory leak. Full details of the upstream changes are available in the official Apache Kafka release announcements and the upgrade guide.

As with all GA releases on our platform, Kafka 4.3.1 has been validated against our operational, reliability, and support standards before being made available to customers. Alongside the Kafka 4.3.1 upgrade itself, we’re also releasing a runtime upgrade to OpenJDK 21 and a new Karapace Schema Registry and REST Proxy version at the same time. Details on both are below.

What’s New in Apache Kafka and Apache Kafka Connect 4.3

Kafka 4.3 is primarily an operator- and reliability-focused release, with 25 Kafka Improvement Proposals (KIPs) and 683 commits since Kafka 4.2.1, our most recently released GA version on the Instaclustr Managed Platform. Below are the changes most relevant to customers running managed Kafka and Kafka Connect clusters.

Broker and Group Coordinator Reliability

  • KIP-1211: Aligns the behavior of num.partitions and default.replication.factor so topic creation is consistent regardless of which values are explicitly specified.
  • KIP-1251: Introduces a per-partition assignment epoch so the group coordinator can distinguish a genuine partition reassignment from a benign, concurrent member epoch bump. This reduces spurious STALE_MEMBER_EPOCH and ILLEGAL_GENERATION errors on offset commits, most notably for transactional producers, which previously had no option but to abort the transaction when fenced.
  • KIP-1263: Improves the group coordinator’s assignment logic to avoid recomputing assignments when unnecessary, reducing coordinator overhead under load.
  • KAFKA-20634 / KAFKA-20635: Fix incorrect HighWatermarkUpdate and “Writing records” failed errors logged by the group coordinator after a partition leadership change.
  • KAFKA-20640: Fixes a bug where a consumer group could incorrectly accept new classic-protocol members even when the migration policy was disabled.

Share Groups (Queues for Kafka)

  • KIP-1240: Adds new group-level configurations for share groups: share.delivery.count.limit, share.partition.max.record.locks, and share.renew.acknowledge.enable, giving share group owners finer control over delivery and lock behavior. Group config validation has also been improved.

Tiered Storage

  • KIP-1023: Extends the ListOffsets API to version 11, adding the EARLIEST_PENDING_UPLOAD_TIMESTAMP timestamp type. Clients can now query the earliest offset on the leader that has not yet been uploaded to remote storage, which is useful for tooling built against tiered storage topics.

Deprecations to Plan For

  • KIP-1237: The group.coordinator.rebalance.protocols broker configuration is deprecated and will be removed in Kafka 5.0.
  • KIP-1274: Consumers using the classic rebalance protocol will now see a log message recommending migration to the newer consumer rebalance protocol ahead of its removal in a future release.

Runtime Upgrade: OpenJDK 21

Kafka and Kafka Connect 4.3.1 on the NetApp Instaclustr Managed Platform now run on OpenJDK 21 (Amazon Corretto), up from OpenJDK 17. This runtime change applies specifically to Kafka and Kafka Connect 4.3.1; clusters running earlier Kafka and Kafka Connect versions on the platform remain on OpenJDK 17 until they are upgraded to 4.3.1.

Newer Java Virtual Machine (JVM) garbage collection (GC) and memory management behavior, summarized here, lowers the risk of heap- and GC-driven broker instability, such as high CPU usage, under-replicated partitions, and offline partitions following a transient load spike or memory pressure event. It also improves how brokers recover when those conditions do occur. Generational ZGC (JEP 439), for example, cuts GC pause times and largely eliminates the allocation stalls that single-generation collectors are prone to under sustained high allocation rates. We ran full regression and performance testing of Kafka 4.3.1 against our current GA baseline, Kafka 4.2.1, before rolling this out.

Karapace Schema Registry and REST Proxy 6.2.1

We’re also updating the Karapace Schema Registry and REST Proxy add-on to version 6.2.1, bringing customers up to the latest Karapace release. Karapace is versioned and released independently of Kafka, and this update is available across all currently supported Kafka versions on the platform, not just Kafka 4.3.1. We recommend customers running Karapace upgrade to 6.2.1; as with any Karapace version bump, we recommend validating against a non-production environment first, since REST Proxy and Schema Registry API behavior can change between versions.

For customers using Karapace’s Schema Registry, this update includes added support for Avro schema references, so schemas can refer to other registered schemas instead of duplicating shared type definitions, and a fix that preserves Protobuf map<K,V> field types through binary serialization and schema normalization, which previously could be lost. Note that Karapace 6.0.0 removed the built-in backup and restore functionality (the karapace_schema_backup CLI tool and karapace.backup module) as part of patching a path traversal vulnerability in the backup reader; customers relying on Karapace’s native backup/restore feature should review the Karapace 6.0.0 release notes before upgrading.

Lifecycle Guidance and Upgrade Recommendations

With the release of Kafka 4.3.1, we have reviewed and updated the lifecycle states of older Kafka versions in accordance with our published Lifecycle Policy. To ensure continued access to full support and SLAs, we recommend that customers:

  • Run GA versions of Kafka and Kafka Connect wherever possible
  • Upgrade Kafka and Kafka Connect clusters at least once per year to a current GA release
  • Plan upgrades proactively, especially when running older patch versions

Before upgrading production clusters, we strongly recommend validating Kafka 4.3.1 in a non-production environment to confirm compatibility with your Kafka clients, connectors, and applications. Customers running Kafka Streams applications should separately plan to upgrade their own application’s kafka-streams dependency, as Streams runs as a client-side library and is not upgraded as part of the managed broker cluster.

Details of all Kafka versions currently supported on the Instaclustr Managed Platform are available on our Lifecycle Status of Application Versions page.

Getting Started or Upgrading

Ready to put Kafka 4.3.1 to work? Whether you’re spinning up a brand-new cluster or upgrading an existing one, our team is on hand to help you get there fast. Reach out via our support website and let’s get moving.