Kafka tiered storage and Kafka compute-storage separation are often discussed in the same architecture review because both use external storage. That overlap can hide the most important difference: tiered storage optimizes where older log segments live, while compute-storage separation changes the ownership model between brokers and durable data.
If the team is asking, "How do we keep more history without expanding broker disks?", tiered storage is the natural starting point. If the team is asking, "Why does every scaling, recovery, and maintenance operation still revolve around broker-local data?", the discussion has moved into kafka compute storage separation, kafka shared storage, and stateless Kafka.
The decision is easier when you compare responsibilities: who owns active data, where producer writes become durable, and whether adding or removing brokers requires moving partition data.
The difference in one sentence
Kafka tiered storage adds a remote tier to a broker-local Kafka storage model. Kafka storage compute separation makes durable log storage a shared layer so brokers can behave more like replaceable compute.
That sentence carries several operational consequences. In Apache Kafka tiered storage, brokers still use local disks for active log segments, tail reads, and the primary write path. Completed segments can be copied to remote storage, and local retention can remove older segments after the remote copy is safe. Consumers still talk to Kafka brokers, and the broker decides whether a fetch can be served locally or needs a remote segment.
In a compute-storage separation design, the target is not "older data goes elsewhere." The target is "durable data is no longer permanently coupled to the broker that serves it." Brokers still process Kafka protocol requests, own leadership at runtime, cache data, and participate in control-plane decisions. The durable source of truth sits in shared storage, often object-storage-backed, with a write-ahead path and metadata layer that protect ordering and ownership.
This is why the phrase "kafka tiered storage vs stateless Kafka" can be misleading. Tiered storage can reduce local disk pressure and improve some recovery scenarios because less historical data must be restored locally. It does not, by itself, make brokers stateless with respect to active log ownership.
What tiered storage optimizes for
Tiered storage is a retention architecture. It recognizes that most Kafka consumers read near the head of the log, while older data is usually read for backfill, replay, or recovery. Apache Kafka's tiered storage documentation describes a local tier that remains the broker disk path and a remote tier for completed log segments stored in external systems such as S3 or HDFS.
That is practical for teams with large retention windows. Without a remote tier, long retention often forces operators to increase local disk capacity or add brokers even when CPU and network are not the limiting resources. With tiered storage, the cluster can keep a smaller local window while retaining older data remotely.
Tiered storage is most useful when the pain looks like this:
- Retention is growing faster than compute demand.
- Broker disks are sized for history rather than active traffic.
- Historical replay is important but less common than tail consumption.
- Operators want old data to remain available through Kafka instead of a separate archive path.
- The team is comfortable keeping active log storage on brokers.
The last point is the boundary. Tiered storage does not remove the need to size local disks for the hot path. It changes how much history stays local. Local retention, segment rolling, remote upload lag, remote metadata, and remote fetch behavior become part of the operational contract.
What compute-storage separation optimizes for
Kafka storage compute separation is an elasticity and ownership architecture. It starts from a different complaint: Kafka brokers serve client traffic, but they also own the local persistent replicas that make scaling, recovery, and replacement heavy.
In a shared-nothing Kafka cluster, adding a broker is not the same as adding useful balanced capacity. Partitions may need reassignment, and data may need to move. Removing a broker safely means moving its local replicas away. Replacing failed infrastructure can be quick at the compute layer but slow at the data placement layer.
Kafka compute-storage separation changes the question from "how much data can I tier out?" to "why does durable log ownership live on the broker at all?" In this model, storage capacity scales with retained data, while broker compute scales with traffic, connections, protocol work, cache, and leadership. The broker becomes less of a local data owner and more of a compute node over a shared durable layer.
Architects usually evaluate this path when the pain looks like this:
- Scaling out takes too long because rebalancing is data-heavy.
- Scaling in is operationally risky because brokers still hold local replicas.
- Recovery objectives are constrained by local disk loss or replica movement.
- Kubernetes or cloud instance replacement clashes with broker statefulness.
- Retention and throughput grow on different curves.
- Platform teams want stateless Kafka broker operations while keeping Kafka compatibility.
Compute-storage separation is not a tuning flag. The hard parts move into shared storage, write-ahead durability, cache design, metadata ownership, and stale-writer fencing. A serious evaluation should inspect those mechanisms rather than accepting the label.
Compare the hot path and cold path
The cleanest comparison is to follow a record through the system.
| Dimension | Kafka tiered storage | Kafka compute-storage separation |
|---|---|---|
| Primary design goal | Reduce broker-local retention burden | Decouple durable data ownership from brokers |
| Write path | Active log segment remains local to broker storage | Writes are protected through shared storage architecture and WAL design |
| Hot reads | Served from local broker storage and cache | Served through broker compute and cache backed by shared durable storage |
| Cold reads | Broker fetches older completed segments from remote tier | Broker reads retained data from the shared storage layer, with cache behavior depending on design |
| Broker disk role | Still important for active segments | Cache or temporary role, not long-term log ownership in a stateless design |
| Scaling bottleneck | Active data and partition placement still matter | Ownership, cache warmup, and traffic placement become the main bottlenecks |
| Failure recovery | Less historical data may need local restoration | Replacement focuses on ownership transfer and rebuilding disposable runtime state |
Tiered storage keeps Kafka's two-tier view: local first, remote for older completed segments. If the local window is too short, routine catch-up traffic can hit the remote tier. If it is too long, broker disks keep carrying much of the burden.
Compute-storage separation has a different test. Ask where an acknowledged write becomes durable and how a replacement broker can take over if the previous leader fails. If the answer depends on files trapped on the failed broker, the system is not stateless in the durable-data sense. If the answer depends on shared durable state plus correct ownership fencing, then the architecture is closer to stateless Kafka.
Data ownership is the real dividing line
Most confusion comes from treating "uses object storage" as the category. Object storage can be a sink target, a remote tier, an archive, a backup target, or the primary durable store for a Kafka-compatible shared-storage system.
The dividing line is data ownership:
- In traditional Kafka, brokers own local persistent replicas.
- In tiered storage Kafka, brokers still own the active local path, while older completed segments can move to remote storage.
- In shared-storage Kafka, durable data ownership moves into a shared layer, and brokers own runtime serving responsibilities.
This matters during a broker failure. In tiered storage, another in-sync replica can take leadership if the Kafka replication contract is satisfied, and remote segments may reduce how much old data is tied to local disks. But active replicas and the local hot path remain part of the broker state model. In compute-storage separation, the goal is for replacement to be mostly an ownership and cache event, not a local-data reconstruction event.
That does not make shared storage easier in every dimension. It has to solve problems that local disks and ISR replication previously handled in a familiar way: write ordering, durability before acknowledgment, leader fencing, metadata consistency, object layout, cache efficiency, and storage-service backpressure. The architecture is worth evaluating when those responsibilities buy back operational elasticity that broker-local Kafka cannot provide.
When tiered storage is enough
Tiered storage is enough when the primary problem is retention offload and the current Kafka operating model is acceptable. A stable cluster with predictable traffic and manageable broker replacement procedures can benefit from a remote tier without changing the whole storage architecture.
It is also a good fit when the team wants to stay close to Apache Kafka's native model. Tiered storage preserves the broker-local primary path and exposes old data through Kafka fetches. It can be rolled out topic by topic, evaluated with local retention settings, and monitored through remote upload, metadata, and remote fetch signals.
Use tiered storage first when your architecture review ends with statements like these:
- "We need longer retention, but most consumers stay near the head."
- "Broker disks are too large because of historical data, not active traffic."
- "We can tolerate different latency for historical replay."
- "We are not trying to redesign broker scaling or make brokers stateless."
- "The current operational model works if storage pressure drops."
The caution is that tiered storage should not be sold internally as full storage-compute separation. If platform leaders expect stateless broker replacement, rapid scale-in, or shared primary storage, a remote tier alone will disappoint them.
When shared storage is worth evaluating
Shared storage is worth evaluating when the architecture pain is broker-data coupling. This often appears after teams have optimized partitions, tuned retention, automated reassignments, and improved broker sizing. The remaining friction is structural: broker instances still carry durable data gravity.
The decision often appears in cloud-native platform work. Kubernetes wants workloads to be schedulable and replaceable. Cloud infrastructure wants compute fleets to expand and shrink with demand. Traditional Kafka can run in those environments, but broker-local persistent data makes it behave differently from stateless services.
Evaluate shared-storage Kafka when your review contains questions like these:
- Can we add broker compute without waiting for large partition data movement?
- Can we remove broker compute without draining local replicas first?
- Can a failed broker be replaced without depending on its attached disk?
- Can storage retention grow independently from broker fleet size?
- Can Kafka remain compatible while the storage layer changes underneath?
Those questions point beyond kafka tiered storage. They point to kafka shared storage, stateless Kafka brokers, and a storage layer that is designed as the durable foundation rather than a secondary tier.
Where AutoMQ fits in the map
AutoMQ sits on the compute-storage separation side of this map. It is a Kafka-compatible streaming platform that keeps the Kafka protocol surface while using object-storage-backed shared storage and stateless brokers as core architecture choices.
That placement is important. AutoMQ is not a synonym for Apache Kafka tiered storage, and tiered storage is not a diminished version of AutoMQ. They answer different architecture questions. Apache Kafka tiered storage extends the broker-local model with a remote tier for completed segments. AutoMQ replaces broker-local persistent log storage with S3Stream and shared storage so brokers no longer act as the long-term owner of durable log data.
For application teams, the value is not a different messaging API. The point is to keep Kafka-facing compatibility for producers, consumers, Kafka Connect, Kafka Streams, and ecosystem tooling while changing the data plane underneath. For platform teams, broker operations can focus more on compute, ownership, cache, and traffic placement rather than local replica data movement.
The evaluation should still be concrete. Ask how writes are acknowledged, where WAL data lives, how object storage is used, how cache misses behave, how stale writers are fenced, what Kafka features are compatible, and how recovery behaves under live traffic. Compute-storage separation is strongest when those answers are precise.
Teams building a shortlist can use the AutoMQ architecture docs as one reference point for evaluating a Kafka-compatible shared-storage implementation.
A practical selection framework
Start by naming the bottleneck before naming the architecture. "We use too much disk" is not precise enough. Too much disk for active data, retained history, replication factor, replay windows, or failed-broker recovery? Each answer points to a different action.
If retained history is the issue, tiered storage is the more direct path. Model local retention around normal consumer recovery, test remote replay, and watch object-store request behavior. The decision is mostly about retention, cold-read expectations, and operational maturity.
If broker statefulness is the issue, compute-storage separation deserves a parallel evaluation. Model scale-out, scale-in, broker failure, zone failure, cold replay, and rolling upgrades. The decision is mostly about ownership, durability, fencing, and whether the shared storage design preserves the Kafka contract.
The key is not to confuse a retention feature with an architecture shift. Tiered storage answers a storage lifecycle question; shared storage answers a broker ownership question.
References
- Apache Kafka 4.3 Tiered Storage Operations
- Apache Kafka 4.3 Tiered Storage Configs
- KIP-405: Kafka Tiered Storage
- Apache Kafka Replication Documentation
- AutoMQ Architecture Overview
- AutoMQ Compatibility with Apache Kafka
FAQ
Is Kafka tiered storage the same as compute-storage separation?
No. Kafka tiered storage adds a remote tier for older completed log segments while keeping active storage on broker disks. Compute-storage separation changes the durable data ownership model so broker compute and storage capacity can scale more independently.
Does Kafka tiered storage make brokers stateless?
No. Tiered storage can reduce how much historical data remains local, but brokers still use local storage for active log segments, hot reads, and the primary Kafka write path. Stateless Kafka requires durable log ownership to move away from broker-local disks.
When should I choose Kafka tiered storage?
Choose tiered storage when your main problem is long retention or broker disk pressure from historical data, and the current Kafka operational model is otherwise acceptable. Test remote replay latency, local retention windows, and remote storage cost behavior before a broad rollout.
When should I evaluate Kafka shared storage?
Evaluate Kafka shared storage when your main problem is broker-data coupling: slow scale-out, hard scale-in, heavy recovery, Kubernetes friction, or retention and compute demand growing on different curves. In that case, the key question is not where cold data lives, but who owns durable data.
Where does AutoMQ fit?
AutoMQ fits the compute-storage separation side. It is Kafka-compatible and uses object-storage-backed shared storage with stateless brokers, so it targets broker elasticity and recovery rather than only retention offload.