Tiered Storage and Diskless Topics: What Is Real

Overview

Tiered storage, which keeps older log segments in remote storage, has been production-ready since Kafka 3.9. That release also let you disable it per topic (KIP-950) and added upload and download quotas (KIP-956). Later releases refine it rather than redefine it. 4.0 changed several thread pool defaults, and 4.3 adds a broker setting, follower.fetch.last.tiered.offset.enable (off by default), that lets a new follower start from the last tiered offset instead of copying the whole log (KIP-1023). Diskless topics are a different matter. KIP-1150 proposes a topic type that keeps all its data in shared object storage, with no local broker disk and no ISR replication, living next to classic topics and chosen per topic. The KIP is accepted, but acceptance covers only the need for the feature: the KIP says it requires no code changes and adds no public interfaces. The implementation is in follow-up KIPs, KIP-1163 (Diskless Core) and KIP-1164 (Diskless Coordinator), and none of the 4.1, 4.2 or 4.3 announcements mention it. Treat diskless as a direction, not something to plan a migration around.

Analogy

Key configuration

Tiered storage settingsproperties

# Changed in 4.0
remote.log.manager.copier.thread.pool.size: -1 -> 10      (-1 is no longer valid)
remote.log.manager.expiration.thread.pool.size: -1 -> 10  (-1 is no longer valid)
remote.log.manager.thread.pool.size: 10 -> 2

# Added in 4.3
follower.fetch.last.tiered.offset.enable=false   # default; KIP-1023
remote.log.metadata.admin.<prop>                 # prefix for the admin client, KIP-1208

Production tip

Check yourself

What does acceptance of KIP-1150 (diskless topics) actually mean?

Sources

Checked against Kafka 4.3 documentation on Oct 2026. Draft: not yet reviewed by a Kafka specialist. Releases move on, so confirm against the current documentation before you act on a number.