Pulsar (Apache-2.0, born at Yahoo) is the most architecturally distinct of the major streaming platforms: where Kafka couples storage to brokers, Pulsar separates them — stateless brokers in front, Apache BookKeeper storage nodes behind. Most of Pulsar's real advantages and real costs flow from that one decision.
A Pulsar broker owns topics but stores nothing durably; messages are written to BookKeeper ledgers — append-only segments replicated across storage nodes (bookies). Consequences:
Tiered storage is native: aged segments offload transparently to S3/GCS while remaining readable through the same API — infinite retention at object-storage prices, which Pulsar shipped years before the Kafka world's equivalent efforts matured.
Pulsar's subscriptions unify what Kafka and RabbitMQ split. A topic supports four subscription modes:
Per-message acknowledgment (vs Kafka's offset-only model) enables selective redelivery, dead-letter policies, and negative acks natively. Multi-tenancy is first-class: tenants and namespaces carry quotas, auth, and policies — designed for a central platform team serving many teams from one cluster, where Kafka typically ends up as cluster-per-team. Geo-replication is built in and bidirectional (no MirrorMaker sidecar).
Pulsar Functions (lightweight per-message compute), Pulsar IO connectors, and Kafka-on-Pulsar (KoP) — a protocol handler letting Kafka clients talk to Pulsar — cover the basics. But the gravitational field is real: Kafka's connector catalog, Streams/ksqlDB tooling, managed offerings, and hiring pool dwarf Pulsar's. Pulsar's strongholds are where its architecture pays: very large multi-tenant deployments (Yahoo, Tencent, Verizon Media scale), queue+stream consolidation, and infinite-retention topics.
Choose Pulsar when: one platform must serve many isolated teams; you need queue semantics and streaming without running two systems; topic rebalancing pain or unbounded retention are live problems; geo-replication is a requirement rather than a wish.
Choose Kafka (or a Kafka-compatible engine) when: ecosystem integration dominates (Connect, Streams, Flink-first tooling, every SaaS exporter); the team is small — one well-understood system beats a more elegant architecture you're alone with; or you want the protocol-compatibility escape hatch the Kafka API uniquely provides.
The architectures are converging — Kafka's KRaft and tiered-storage work adopt Pulsar-ish ideas; the durable differences are multi-tenancy depth, subscription flexibility, and ecosystem mass.