Pulsar

What it is

Apache Pulsar is a distributed messaging and streaming platform built for pub-sub and queuing at scale. It separates compute (brokers) from storage (BookKeeper), which is the core architectural bet that distinguishes it from Kafka — brokers are stateless, storage is a separate layer, and topics can be scaled, partitioned, and rebalanced without moving data around. It supports multi-tenancy natively (tenants → namespaces → topics), geo-replication out of the box, and both streaming and queue semantics on the same topic. Written in Java, it's positioned in the App Definition and Development category because teams use it as the messaging backbone for event-driven architectures, not just log aggregation.

Who builds it and why

791 contributors on GitHub is a large, active base — this isn't a single-vendor side project. Pulsar originated at Yahoo and moved to the Apache Software Foundation; it's now maintained by a broad community with heavy involvement from StreamNative (founded by original Pulsar authors) and contributors from companies running it at scale (Tencent, Splunk, Yahoo/Verizon Media, Iterable, among others cited historically in the project's adopter list). The motivation is architectural: teams that hit scaling walls or operational pain with Kafka's tightly-coupled compute/storage model are the primary audience driving continued investment.

Production readiness signal

15,287 GitHub stars and 791 contributors indicate a mature, broadly-adopted project, not an experimental one. Latest release v4.2.2 shows active semantic versioning and continued feature/patch delivery. Last commit dated 2026-07-01 signals the project is currently maintained (verify this against the actual repo before relying on it — dates this far out should be sanity-checked). License is Apache-2.0, which is enterprise-friendly with no copyleft concerns. CNCF maturity level is not publicly available in the data provided — check the CNCF landscape directly for graduated/incubating/sandbox status before citing it in a vendor comparison, as Pulsar's CNCF status is often referenced in Kafka-vs-Pulsar debates.

Who should use this

• Teams running multi-tenant messaging infrastructure where namespace-level isolation, quotas, and access control matter (SaaS platforms, internal platform teams serving many product teams).
• Organizations needing geo-replication across regions without bolting on external tooling.
• Teams that need both queue semantics (shared subscriptions) and streaming (exclusive/failover subscriptions) on the same data without running two separate systems.
• Anyone who has outgrown Kafka's operational model and wants independent scaling of storage vs. compute, or tiered storage to offload cold data to S3/GCS cheaply.

Who should NOT use this

• Small teams with a single simple event bus need — Pulsar's operational surface (brokers, bookies, ZooKeeper or its replacement, proxies) is heavier than running a single Kafka cluster or using a managed queue like SQS.
• Shops already deeply invested in the Kafka ecosystem (Kafka Streams, ksqlDB, Connect ecosystem maturity) — migration cost rarely pays off unless you're hitting Kafka's specific architectural limits.
• Teams without dedicated platform/SRE capacity — Pulsar has more moving parts than Kafka, and BookKeeper operations knowledge isn't as commoditized as Kafka ops knowledge in the job market.
• Use cases needing simple point-to-point messaging (RabbitMQ or cloud-native queues are simpler and cheaper to operate).

Alternatives

• Apache Kafka — the incumbent; larger ecosystem, more operational tooling and hiring pool, but tightly coupled storage/compute.
• NATS/NATS JetStream — lighter-weight, simpler ops model, less feature-rich for multi-tenancy and geo-replication.
• AWS Kinesis / Google Pub/Sub — fully managed alternatives if you want to avoid operating messaging infrastructure entirely and can accept vendor lock-in.

Pricing

Apache Pulsar itself is fully open source under Apache-2.0 — no license fees. Cost is operational: infrastructure (brokers, bookies, metadata store), and engineering time to run it. Managed offerings exist (StreamNative Cloud, DataStax Astra Streaming) if you want to offload operations — pricing for those is not publicly available here and varies by vendor/usage.