Event-Driven Architectures with Apache Pulsar

Apache Kafka has been the default event-streaming platform for a decade. Pulsar has been the credible alternative — substantially better on several dimensions, less mature on operational tooling. By 2026 the operational maturity gap has closed materially; Pulsar deployments at substantial scale (Yahoo, Tencent, Splunk, DigitalOcean, Iterable, the various) demonstrate that production Pulsar is workable.

This post walks through where Pulsar genuinely fits and where it doesn’t.

The architectural differences#

The substantial architectural differences between Pulsar and Kafka:

Separation of compute and storage. Pulsar’s brokers are stateless; storage is in BookKeeper. Kafka couples broker and storage. This produces different scaling characteristics.

Tiered storage native. Pulsar’s tiered storage (hot data in BookKeeper, cold data in object storage) is more mature than Kafka’s KIP-405-based equivalent. Substantial cost reduction for long-retention workloads.

Multi-tenancy native. Pulsar’s tenancy model (tenants, namespaces, topics) is substantially more developed than Kafka’s. For multi-tenant deployments this matters.

Multi-protocol. Pulsar supports Kafka protocol (KoP) plus its own native protocol. Kafka is Kafka-only.

Geo-replication native. Pulsar’s geo-replication is more mature than Kafka’s MirrorMaker.

Topic compaction model. Different from Kafka’s. Each has trade-offs.

Where Pulsar wins#

Several substantial wins for Pulsar:

Long-retention workloads with tiered storage. When you want to keep months or years of events with predictable economics, Pulsar’s tiered storage substantially outperforms Kafka’s.

Multi-tenant SaaS. When you’re running event streaming for many customers/tenants with isolation requirements, Pulsar’s multi-tenancy is substantially better.

Geo-replicated workloads. When events need to flow across multiple geographic regions, Pulsar’s geo-replication is operationally smoother than MirrorMaker.

Mixed workload patterns. Pulsar handles queuing (subscription-based, message-acknowledge model) and streaming (consumer-group, offset model) in one platform. Kafka is streaming-only.

Heavy fan-out. Pulsar’s broker-storage separation handles substantial fan-out scenarios well.

Where Kafka wins#

Several substantial wins for Kafka:

Ecosystem. The Kafka ecosystem (Kafka Connect, Kafka Streams, ksqlDB, Schema Registry, plus the various third-party tools) is substantially larger than Pulsar’s.

Operational tooling and community. Substantially more material exists for Kafka operations. The community is larger.

Cloud managed services. Confluent Cloud, AWS MSK, Azure Event Hubs (Kafka mode), GCP Managed Service for Kafka — all substantial. Pulsar managed (StreamNative, plus various) is smaller.

Talent availability. Substantially more engineers have Kafka experience than Pulsar.

Default-choice gravity. Most organizations already have Kafka. Adding Pulsar requires deliberate decision; staying on Kafka doesn’t.

The operational profile#

Pulsar’s operational characteristics:

BookKeeper as separate cluster. You’re operating BookKeeper plus Pulsar brokers plus ZooKeeper (or Oxia, increasingly). More moving parts than Kafka.

Tiered storage requires object storage. S3 or equivalent. Adds dependency.

Substantial monitoring requirements. Brokers, BookKeeper bookies, ZooKeeper/Oxia, tiered storage — substantial metric coverage needed.

Updates and version management. Pulsar has frequent releases; production teams need disciplined update process.

The operational complexity is real. Teams with substantial Kafka experience can learn Pulsar; teams new to event streaming should think carefully.

The cost profile#

Cost comparison Pulsar vs Kafka:

At small scale, Kafka is typically cheaper because the operational simplicity wins.

At medium scale with substantial retention, Pulsar with tiered storage frequently wins on substantial margin.

At large scale with multi-tenancy, Pulsar’s architectural advantages produce substantial cost benefits.

At any scale with geo-replication, Pulsar’s native capability frequently wins.

The math is workload-dependent.

The decision framework#

For most teams in 2026:

Stay on Kafka if you’re already on Kafka and not hitting specific Pulsar advantages. The switching cost is substantial; the gain has to justify it.

Pick Pulsar if you’re greenfield and your workload profile favors Pulsar (long retention, multi-tenancy, geo-replication, mixed queue+stream patterns).

Pick Pulsar via managed service (StreamNative, plus various) if you want Pulsar’s advantages without the operational complexity.

Pick cloud-native equivalents (Kinesis, Pub/Sub, Event Hubs in non-Kafka mode) if you’re committed to cloud-vendor lock and the proprietary services fit.

What we typically see at clients#

Common patterns:

Default Kafka. Most enterprises default to Kafka without serious Pulsar evaluation. Often the right choice; sometimes leaving substantial value on the table.

Pulsar at second-generation event streaming. Organizations on second event-streaming platform sometimes pick Pulsar specifically for the things Kafka didn’t do well.

Pulsar for specific workloads. Some organizations run Kafka primary plus Pulsar for specific workloads (geo-replicated, long retention).

Cloud managed Kafka as practical default for most use cases — Confluent Cloud, MSK, plus the various.

Where pdpspectra fits#

Our data platforms practice builds production event-streaming platforms with appropriate technology selection.

Related reading: the streaming SQL post, the change data capture post, and the data mesh post.

---

Event streaming platform choice depends on workload. Talk to our team about your event-streaming architecture.