vs Apache Pulsar
Apache Pulsar is an enterprise-grade, multi-tenant distributed messaging and streaming platform with multi-layered architecture (brokers + BookKeeper for storage + ZooKeeper for coordination). It is arguably the most fully-featured open-source broker available.
Use Pulsar when
- You need geo-replication across data centres.
- You need multi-tenancy with strict namespace isolation between teams or customers.
- You need tiered storage (offload old data to S3/GCS automatically).
- You need Kafka-compatible consumers (via Pulsar’s KoP protocol handler).
- You have a dedicated ops team that can manage a cluster of minimum 6 nodes (3 brokers + 3 BookKeeper nodes), or a managed service like StreamNative.
- You need Pulsar Functions for serverless stream processing close to the broker.
Use tinybroker when
- You cannot justify or operate a 6-node JVM cluster for an internal coordination bus. Pulsar’s minimum viable production deployment is a cluster — there is no “single node for small workloads” mode that provides the same API. (There is a standalone mode for development, but it is not production-grade.)
- You want a single static binary that starts in milliseconds with no JVM, no BookKeeper, no ZooKeeper.
- Your use case is intra-service coordination within a single deployment unit, not enterprise streaming across teams and data centres.
- Messages may be lost on restart and you want no storage management, no retention policies, no topic compaction.
The core trade-off
Pulsar is the right answer when you need everything: persistence, replication, multi-tenancy, tiered storage, and a rich ecosystem. It is overkill when you need a lightweight fan-out bus between five replicas of a Go service. tinybroker covers the latter; Pulsar covers the former.