Skip to content

CONCEPT Cited by 1 source

Mountable tiered-storage topic

Definition

A mountable tiered-storage topic is a Kafka-API topic whose data already lives in an object store via tiered storage, and which can be safely unmounted from a cluster (hidden from the active topic set, freeing its in-cluster resources) and later re-mounted — to the same cluster, a different cluster, or the same cluster with a different name — with zero data loss.

Introduced by Redpanda in the 24.3 release (2024-12-03) as Mountable Topics — a generalisation of tiered storage's fast-decommission property from the broker-lifecycle altitude to the topic-lifecycle altitude.

Canonical Redpanda framing

"'Hibernate' unused topics to conserve cluster resources and maximize cost savings and flexibility. You can now mount and unmount unused Tiered-Storage topics from a Redpanda cluster safely with zero data loss. This allows you to use 100% of your cluster capacity to support your primary workloads while preserving the full history of other workloads. It also makes them easy and cost-effective to recreate — even in a new cluster and with a new name."

(Source: sources/2024-12-03-redpanda-redpanda-243-extends-lakehouses-with-streaming-data-cdc)

Why it exists — the problem a mountable topic solves

Conventional Kafka topics are always-resident: once created on a cluster, the broker holds their metadata, allocates partition leaders, replicates followers, and polls them during operations (rebalances, decommissions, compaction, etc.) even if nothing produces or consumes from them. A workload that's been retired — but whose history the operator still wants preserved for audit, compliance, or future re-analysis — pays ongoing cluster-resource cost proportional to its metadata + replica footprint.

Mountable topics decouple data durability from cluster residency. The data remains in object storage (the tiered-storage substrate the topic was using anyway); the topic itself is removed from the cluster's active set until re-mounted.

The unmount / mount lifecycle

  • Unmount: the broker detaches the topic from its active set. In-cluster metadata + partition-leader assignments are released. The data in object storage is untouched.
  • Mount: the broker (any broker — the original cluster or a different one) attaches the object-store data back into the cluster's active set as a topic with whatever name the operator chooses.

The operator surface is explicit CLI verbs:

"The rpk CLI and Redpanda Cloud API feature new mount and unmount commands for topics using Tiered Storage."

Contrast with remote read replica topics

Mountable topic concepts/remote-read-replica-topic
Source of data Object-store segments the origin wrote Object-store segments the origin wrote
Active cluster Exactly one at a time (unmounted = zero) Origin + any number of read-only replicas
Read/write Read + write when mounted Read-only
Primary use Hibernate / relocate workloads Scale read fan-out without loading origin

Mountable topics are a lifecycle primitive (present / absent); remote read replicas are a read-scaling primitive.

Availability

Enterprise feature on self-managed Redpanda Enterprise and Redpanda Cloud BYOC + Dedicated at launch (24.3, 2024-12-03). Not available on Redpanda Cloud Serverless.

Seen in

Last updated · 550 distilled / 1,221 read