The combination of features that makes Apache Pulsar more than just a message broker.
Scales horizontally to handle the increased load. Its unique design and separate storage layer enable controlling the sudden surge in traffic by scaling out in seconds.
Acknowledge messages individually (RabbitMQ style) or cumulative per partition (i.e., offset-like). Enables use cases such as distributed work queues or order-preserving data streams at massive scales (hundreds of nodes) and low latency (<10ms).
Pulsar's unique architecture supports up to 1 million topics in a single cluster. Simplify your architecture by avoiding multiplexing multiple streams into a single topic.
Maintain one cluster for your entire organization using tenants. Control which user has access across data (namespaces/topics) and actions (produce/consume/…).
Add or remove nodes and let Pulsar load balance topic bundles automatically. Hot spotted topic bundles are automatically split and evenly distributed across the brokers.
Pulsar was built for the cloud from day one. Both Pulsar and Bookkeeper nodes can scale up quickly as Pulsar is stateless, and Bookkeeper was designed to avoid data reshuffling while still utilizing all newly joined nodes.
Protect against complete zone outages using replication across different geographic regions. Flexible and configurable replication strategies across distant Pulsar Clusters. Uniquely supports automatic client failover to healthy clusters.
Officially maintained Pulsar Clients for Java, Go, Python, C++, Node.js, and C#.
Unlimited retention by seamless data offloading from Bookkeeper to blob storage (e.g., S3). Keep high performance with resiliency by keeping warm data both in Bookeeper and S3.
Support validating incoming and outgoing data against a topic schema. Future proof by supporting backward and forward compatibility checks for each new schema version.
Pulsar supports user authentication with the ability to set access to specific namespaces or topics with limited permissions (consume, produce, etc.)
Pulsar writes to Bookkeeper are guaranteed to be written to disk (a.k.a fsync), providing high resiliency to machine failures. It can be disabled to favor higher throughput.
Choose the best instance types for storage and CPU separately due to Pulsar's unique architecture. Support massive parallel query engines by a direct read from Bookkeeper.
Use popular messaging system clients with Pulsar as the backend, powered by community plugins: Kafka, RabbitMQ, and more. This facilitates moving to Pulsar gradually.
Write and deploy functions natively using Pulsar Functions. Process messages using Java, Go, or Python without deploying fully-fledged applications. Kubernetes runtime is bundled.
Write and deploy functions natively using Pulsar Functions. Process messages using Java, Go, or Python without deploying fully-fledged applications. Kubernetes runtime is bundled.
Very large messages are welcomed in Pulsar, using client-side chunking.
Write a message with a given delay before it is available for consumption. Great for scheduled tasks and exponential back-off retries.
Supports a large number of concurrently connected consumers to a topic, regardless of partition count.
Zookeeper is just one of the plugins for the metadata store. Quickly isolate metadata-related issues as the system is separated from Pulsar itself. Allows future scalable metadata stores.
Built-in REST API and CLI for administrative operations
Flexible message retention
By time, size, or unacknowledge size
Topic compaction
Keep only the last of the same key messages.
Message deduplication
Achieve Exactly Once when producing.
Transactions
Produce and acknowledge as an atomic operation