diff --git a/modules/get-started/pages/release-notes/redpanda.adoc b/modules/get-started/pages/release-notes/redpanda.adoc
index a07d192479..7de1b008c6 100644
--- a/modules/get-started/pages/release-notes/redpanda.adoc
+++ b/modules/get-started/pages/release-notes/redpanda.adoc
@@ -19,12 +19,42 @@ Redpanda can now export a cluster health summary as Prometheus metrics, so you c
 
 To enable them, set xref:reference:properties/cluster-properties.adoc#health_monitor_metrics_enabled[`health_monitor_metrics_enabled`] to `true` and restart your brokers. See xref:manage:monitoring.adoc#cluster-health[Cluster health] for the available metrics and query patterns.
 
+== Shadowing: migrate schemas from Confluent Schema Registry
+
+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 xref:manage:disaster-recovery/shadowing/migrate-schemas-confluent.adoc[Migrate Schemas from Confluent].
+
+== Shadowing: role synchronization
+
+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 xref:manage:disaster-recovery/shadowing/setup.adoc#role-filtering[Configure Shadowing].
+
 == Kafka 4.x client compatibility
 
 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 xref:develop:kafka-clients.adoc[Kafka Compatibility] for the full list of validated clients and known exceptions.
 
+== Fetch read coalescing
+
+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 xref:manage:cluster-maintenance/fetch-read-coalescing.adoc[Fetch Read Coalescing].
+
+== Per-entity client quota metrics
+
+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 xref:manage:cluster-maintenance/manage-throughput.adoc#track-quota-use-per-entity[Manage Throughput].
+
+== Cloud Topics enabled by default
+
+Cloud Topics no longer require a separate cluster property. When cloud storage is enabled for your cluster (xref:reference:properties/object-storage-properties.adoc#cloud_storage_enabled[`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 xref:develop:manage-topics/cloud-topics.adoc[Manage Cloud Topics].
+
 == Shadowing support for Cloud Topics
 
 Shadow links now support Cloud Topics, so you can include Cloud Topics in disaster recovery replication alongside standard topics.
diff --git a/modules/manage/pages/cluster-maintenance/manage-throughput.adoc b/modules/manage/pages/cluster-maintenance/manage-throughput.adoc
index 6b059ed831..25e1bc0854 100644
--- a/modules/manage/pages/cluster-maintenance/manage-throughput.adoc
+++ b/modules/manage/pages/cluster-maintenance/manage-throughput.adoc
@@ -729,7 +729,7 @@ endif::[]
 
 ==== Track quota use per entity
 
-When a workload slows down because a client hits its throughput quota, the aggregate quota metrics can confirm that throttling is happening, but they cannot tell you which client is being throttled or how close each client is to its limit. Per-entity quota metrics answer these questions. Redpanda labels each throttle-time and throughput series with the identity of the throttled entity, so you can measure how much of an enforced quota each client actually uses. Use these metrics to identify throttled clients by name and right-size quota values based on observed usage.
+When a workload slows down because a client hits its throughput quota, the aggregate quota metrics can confirm that throttling is happening at a broker level, but they cannot reveal which user, client, or group of clients is utilizing a quota or being throttled. Per-entity quota metrics answer these questions. Redpanda labels each throttle-time and throughput series with the identity of the throttled entity, so you can measure how much of an enforced quota each entity actually uses. Use these metrics to identify throttled users and clients by name and right-size quota values based on observed usage.
 
 Per-entity quota metrics are disabled by default because each throttled entity adds metric series.