What’s New in Redpanda

Shadowing can now replicate schemas over the Schema Registry HTTP API, including from a Confluent Schema Registry. Both Confluent Cloud and Confluent Platform are supported. A shadow link continuously replicates subjects, versions, and compatibility settings into the shadow cluster’s Schema Registry, so your applications keep working after cutover without a separate schema migration step. You can also replicate only selected contexts or subjects, and map source contexts to different destination contexts.

See Migrate Schemas from Confluent.

Shadow links can now replicate cluster roles from the source cluster to the shadow cluster, alongside topics, ACLs, consumer group offsets, and Schema Registry data. This ensures equivalent RBAC is in place on the shadow cluster prior to failover. Configure role filters to select which roles to sync.

See Configure Shadowing.

Shadow links now support Cloud Topics, so you can include Cloud Topics in disaster recovery replication alongside standard topics.

See Configure Shadowing.

Redpanda version 26.2 validates a broader set of non-Java Apache Kafka® clients at their current versions that support Kafka 4.x, in addition to the Apache Kafka Java client. Newly validated clients include confluent-kafka-go and Sarama for Go, and kafka-python and confluent-kafka-python for Python. Validation confirms connectivity and correctness across core Kafka APIs, such as produce, consume, and transaction operations.

See Kafka Compatibility for the full list of validated clients and known exceptions.

You can now keep a feature-release upgrade open, soak testing the new version with a guaranteed rollback path, and finalize the upgrade when you are ready. For clusters in a Shadowing topology, new guidance covers upgrade order: upgrade the shadow cluster before the source cluster, and use deferred finalization for bidirectional topologies.

See Defer Upgrade Finalization and Upgrade Clusters in a Shadowing Topology.

When many consumers fetch the same partitions, each broker repeats the same read work for every consumer. Fetch read coalescing merges these redundant reads on each shard, reducing read CPU and memory consumption under high consumer fan-out. This Enterprise feature is disabled by default: enable it with the kafka_fetch_read_coalescing_enabled cluster property.

See Fetch Read Coalescing.

Aggregate quota metrics can confirm that throttling is happening at a broker level, but don’t reveal which user, client, or group of clients is utilizing a quota, or being throttled. Redpanda can now label throttle-time and throughput metrics with the identity of the throttled entity, so you can identify throttled users and clients by name and right-size quota values based on observed use. These metrics are disabled by default: enable them with the kafka_per_entity_quota_metrics cluster property.

See Manage Throughput.

Cloud Topics no longer require a separate cluster property. When cloud storage is enabled for your cluster (cloud_storage_enabled set to true), you can create Cloud Topics immediately by setting the storage mode during topic creation. The cloud_topics_enabled cluster property is deprecated.

See Manage Cloud Topics.

Bind a topic’s Iceberg translation to a specific Schema Registry context using the new redpanda.schema.registry.context topic property, instead of always using the default context. This is useful for multi-tenant or per-environment schema isolation.

See Resolve schemas within a Schema Registry context.

Independently control how Redpanda translates a record’s key, value, and headers into the Iceberg table with a new section-based syntax for the redpanda.iceberg.mode topic property. You can decode keys and values using a schema registered in the Schema Registry, store keys or values as UTF-8 strings, or decode header values from raw bytes to strings. The key_value, value_schema_id_prefix, and value_schema_latest modes continue to work as shorthand for common combinations.

See Specify Iceberg Schema.

Monitor the health of Iceberg topics with a new Admin API endpoint, including connectivity to the external REST catalog and per-partition commit lag. Use it to test the catalog connection and find the partitions with the highest commit lag.

See Monitor Iceberg health.

Redpanda can now export a cluster health summary as Prometheus metrics, so you can alert on overall cluster health, such as brokers down, leaderless partitions, or a missing controller, directly from your metrics system instead of polling rpk cluster health. The metrics mirror the output of rpk cluster health and are disabled by default.

To enable them, set health_monitor_metrics_enabled to true and restart your brokers. See Cluster health for the available metrics and query patterns.

Tiered Storage v2 is a beta feature. It is not supported for production deployments. Beta features are available for users to test and provide feedback.

Tiered Storage is now available in two versions. Tiered Storage v2 (tiered_v2) adds full compaction support for topics stored in object storage: compaction runs on the data in object storage rather than on local data only, eventually retains only the latest value for each key across the entire partition, and removes tombstone records after the retention period configured by delete.retention.ms. Topics using Tiered Storage v2 can also be converted to and from Cloud Topics.

You enable both versions the same way, by setting redpanda.storage.mode=tiered on a topic. The default_redpanda_storage_mode_tiered_impl cluster property selects the version for new topics (tiered_v1 remains the default), and existing topics keep the version they were created with.

See Choose a Tiered Storage version.

Redpanda 26.2 introduces the following rpk changes:

Shadowing:

Schema Registry:

Metrics and monitoring:

Performance:

Tiered Storage:

Iceberg:

Cloud Topics:

Object storage I/O:

See Deprecated features for the complete list of deprecated properties.

The following cluster properties were introduced in Redpanda v26.1.14 but are not included in v26.2.1. They are available starting in v26.2.2:

If you upgrade from v26.1.14 to v26.2.1, any values you set for these properties are not honored until you upgrade to v26.2.2.

Cluster administration moves fully under rpk cluster: broker decommissioning, recommissioning, logger control, and per-broker configuration and partition listings now live alongside the other cluster commands, and rpk cluster info -b --detailed reports broker membership, liveness, and versions. The rpk redpanda admin command tree is deprecated and hidden from help output. The old commands still work and print a pointer to their replacements, but they are planned for removal in a future major release.

See Deprecated Features for the full command migration table.