Pulsar vs Kafka

Apache Pulsar and Apache Kafka compete for the same streaming workloads, but Pulsar's architecture was designed to address Kafka's known pain points — storage-compute coupling, scaling friction, and multi-tenancy limitations.

Storage-Compute Separation

Kafka brokers are stateful — they store partition data on local disk. Scaling means moving data between brokers (partition reassignment), which is slow and operationally risky.

Pulsar brokers are stateless. They serve topics but store no data. Apache BookKeeper stores data in distributed ledgers. You can add brokers instantly (no data movement) and add bookies for more storage (new data distributes automatically).

Subscription Flexibility

Kafka offers one consumption model: consumer groups where each partition is assigned to one consumer. If you have 10 partitions, you can have at most 10 consumers in a group.

Pulsar offers four subscription modes:

• Exclusive: One consumer per subscription
• Shared: Messages distributed round-robin across consumers (no ordering)
• Key-Shared: Messages with the same key go to the same consumer (ordering per key)
• Failover: Active-standby for high availability

Shared and key-shared subscriptions decouple parallelism from partition count — a significant flexibility advantage.

Tiered Storage

Pulsar natively offloads older data to object storage (S3, GCS, Azure Blob Storage). This dramatically reduces storage costs for long-retention topics. Kafka's tiered storage (KIP-405) has been in development for years and is not yet universally available.

The Ecosystem Gap

Pulsar's biggest challenge is Kafka's ecosystem dominance. Kafka Streams, ksqlDB, Kafka Connect, and thousands of tutorials, courses, and job listings create a network effect that Pulsar has not matched.

For system design interviews, understanding Pulsar shows architectural depth beyond the Kafka default. See our stream processing concepts for more.