All stacks · Streaming & CDC

Apache Pulsar

Multi-tenant messaging with segment storage and built-in functions.

Illustrated overview of Pulsar Multi-Tenant Messaging: Brokers, BookKeeper, and When Not to Leave Kafka

Apache Pulsar

Aug 24, 20264 min read

Pulsar Multi-Tenant Messaging: Brokers, BookKeeper, and When Not to Leave Kafka

Brokers are stateless. BookKeeper holds the log. Pulsar wins on tenant isolation and geo. A healthy Kafka cluster is not a fashion problem.

pulsar
streaming

About Apache Pulsar

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.

What you'll learn here

Topics, subscriptions, and exclusive vs shared vs failover
Segment storage vs Kafka’s partition log
When Pulsar Functions belong in the path vs a Flink job
Ops: BookKeeper disks, backlog, and why “it is like Kafka” is a half-answer

Frequently asked questions

Should I replace Kafka with Pulsar?

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.

Is Pulsar easier to operate?

Different, not easier. You operate brokers and bookies. Capacity planning moves from “partition count” to “ledger disks.” Budget the people before the slide.

Can Debezium write to Pulsar?

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.

New Apache Pulsar posts, straight to your inbox

One email a week with our latest tutorials. No spam.

Newsletter signup is not live yet. Use the contact form if you want to be notified.