All stacks · Streaming & CDC
Multi-tenant messaging with segment storage and built-in functions.
Apache Pulsar🟢BeginnerBrokers are stateless. BookKeeper holds the log. Pulsar wins on tenant isolation and geo. A healthy Kafka cluster is not a fashion problem.
Kafka🟡IntermediateThe architectural differences that actually change operations — segment storage versus partition-as-log, tiered offload, and tenant isolation — plus an honest account of when leaving a healthy Kafka cluster is a mistake.
Apache Pulsar separates compute (brokers) from storage (BookKeeper), which is why multi-tenant messaging shops like it versus a single Kafka log per cluster. Geo-replication and functions are native, not an afterthought.
Most data engineers will still meet Kafka first. Learn Pulsar when the platform is already Pulsar, or when you are comparing multi-tenant messaging with Kafka + MirrorMaker.
Not for fashion. Kafka’s ecosystem (Connect, Flink, Debezium) is the default. Pulsar wins specific multi-tenant and geo stories. A rewrite of a healthy Kafka platform is a year of risk.
Different, not easier. You operate brokers and bookies. Capacity planning moves from “partition count” to “ledger disks.” Budget the people before the slide.
Possible via connectors or a Kafka-compatible layer, but the well-trodden path is Debezium → Kafka. Confirm the connector SLA before you design around it.
