Apache Pulsar Support Options: Community, Vendor or Independent

Apache Pulsar has no vendor. Pulsar support comes from the Apache Pulsar community for supported releases, from StreamNative and other vendors for their own Pulsar platforms and cloud services, and from independent providers for the self-managed Pulsar clusters that most enterprises actually run. Pulsar is also three systems in one, which shapes what support has to cover.

What the Apache Pulsar project supports

The project publishes a time-based release policy. Long-term support (LTS) releases arrive every 18 months, with feature releases every three months in between. An LTS release gets 24 months of active support and 36 months of security support. A feature release gets six months. The project supports the last two LTS releases and the last two feature releases, and provides security patches for the past three LTS releases.

At the time of writing Pulsar 4.0, released in October 2024, is the LTS line in active support, until October 2026 with security support to October 2027, and Pulsar 5.0 is the next LTS. Pulsar 3.x and 2.x have reached end of life. Support here means releases and patches. The community answers questions on Slack, the mailing lists and GitHub, with no response time and no obligation.

Commercial Pulsar vendors

StreamNative, founded by original Pulsar developers, sells a managed Pulsar cloud and a self-managed platform with support. Other vendors have offered Pulsar-based services over the years, and cloud availability changes. Vendor support covers the vendor's distribution and service. If you run the Apache release yourself, which is the common case in regulated and on-premises estates, you are outside it.

Why Pulsar support is harder than broker support

A Pulsar cluster is brokers, Apache BookKeeper for storage, and a metadata store that is usually ZooKeeper. Most serious incidents are not in the broker at all. They are BookKeeper journal latency on a shared disk, a ZooKeeper session expiry that makes brokers drop topic ownership, or a ledger that cannot be recovered because too many bookies were lost. Support that only knows the Pulsar admin API cannot fix those. It needs people who run BookKeeper and ZooKeeper in production.

The Pulsar incidents that actually page people

• Backlog quota exceeded. A consumer stops or slows, the subscription backlog reaches its quota, and depending on the retention policy Pulsar either blocks producers or discards the oldest data. The application sees publish failures that have nothing to do with the producer.
• BookKeeper write latency. Journal and ledger directories share a device, a disk degrades, or garbage collection compaction saturates IO. Publish latency climbs across every topic at once, because every write waits on a quorum of bookies.
• Topics bouncing between brokers. The load balancer unloads bundles from a busy broker, clients reconnect, and the move itself causes the load that triggers the next unload. Bundle splitting and load shedding thresholds need tuning for the real topic count.
• Direct memory exhaustion. Brokers hold the managed ledger cache and in-flight messages in direct memory. Large messages, many subscriptions with backlog and generous cache settings end in an out-of-memory restart.
• Geo-replication lag. Replication between clusters falls behind on a slow link, the replication backlog grows inside the source cluster, and it consumes the same storage and quotas as any other subscription.
• Too many topics. Millions of topics are possible and every one costs metadata. ZooKeeper becomes the limit long before the brokers do.

Upgrading off an end-of-life Pulsar version

Pulsar supports rolling upgrades, and the order matters: ZooKeeper, then bookies, then brokers, then proxies, with functions workers and clients afterwards. Estates on 2.x face the largest jump. The safe route is through the supported upgrade path to an LTS release, not directly to the newest version, reading the upgrade notes for each step because defaults around load balancing, metadata handling and the BookKeeper version change between lines. Clients are compatible across a wide range of broker versions, which lets the cluster move first. Rehearse on a cluster with realistic topic counts, since metadata operations are what slow down at scale.

What to ask a Pulsar support provider

• Do you support BookKeeper and ZooKeeper, or only the broker? If the answer is only the broker, most of your incidents are out of scope.
• Which versions? A provider that only supports the current LTS is no help to a 2.10 cluster.
• Who answers at 3am? Ask whether the emergency response is an engineer who can log in and diagnose, or an acknowledgement that a ticket exists.
• Can you run the upgrade? Advice is cheap. Ask for a provider that will plan, rehearse and execute the rolling upgrade with you.
• What about Pulsar Functions, IO connectors and the proxy? These are where many production problems surface first, and they are often excluded.
• Kubernetes or bare metal? Pulsar on Kubernetes adds persistent volume, anti-affinity and operator questions that a provider should already have opinions on.

Where independent Pulsar support fits

AceMQ provides 24/7 Apache Pulsar support for self-managed clusters on any version, covering brokers, BookKeeper and ZooKeeper, with a 15-minute emergency SLA and named senior engineers. Examples of the work: a BookKeeper IO remediation and backlog quota and throttling support. If you are weighing Pulsar against Kafka, the Kafka vs Pulsar comparison covers the operational differences, and message broker support options compared sets nine brokers side by side.