Apache Pulsar Consulting & Services

Apache Pulsar Consulting & Services for Enterprises

Pulsar's split between the broker layer and BookKeeper storage layer is the thing that makes it different from Kafka — and the thing that trips up teams who operate it like Kafka. AceMQ engineers design and run Pulsar clusters with that separation front of mind.

A senior engineer, not an SDR. No sales sequence attached.

Senior SMEs
11+
Emergency SLA
<15min
Customers
160+
Countries Served
26+

Without migrating off Pulsar or collapsing back to KafkaFor production incident cover, see AceMQ Apache Pulsar 24/7 support.

Customers

  • Microsoft
  • Henry Schein
  • Enbridge
  • Gojek

Partners

  • Broadcom
  • Redis
  • VMware Tanzu
  • OSSeva

The Problem

Why teams call us about Apache Pulsar

Eight Apache Pulsar problems that teams bring to AceMQ: backlog on one subscription, bookies filling up, bundles that keep moving, and clusters run like Kafka when the broker and storage split is behind every incident. If one describes your week, that is where the review starts.

  1. 01

    Backlog builds on one subscription and the storage cost for the whole topic grows with it

  2. 02

    Bookies fill up because ledger retention was never aligned with topic retention

  3. 03

    The load balancer keeps reassigning bundles and clients spend their time reconnecting

  4. 04

    Key_Shared consumers are unevenly loaded and one instance does most of the work

  5. 05

    Tiered storage offload is enabled but reads from offloaded segments are too slow to use

  6. 06

    Geo-replication falls behind quietly and nobody finds out until a failover is needed

  7. 07

    The cluster was operated as though it were Kafka, and the broker and storage split is now behind every incident

  8. 08

    One engineer understands BookKeeper, and every storage question routes through them

A good fit if you run Apache Pulsar in production, or are weighing it against Kafka, and want senior engineers who treat BookKeeper as a first-class part of the system.

Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy Apache Pulsar.

Running Apache Pulsar in production? Get a quote from a senior engineer, answered within one hour.

Contact Us

How it breaks, and the fix

What happens when one Pulsar bookie slows down?

If the ack quorum equals the write quorum, every write waits for the slowest bookie. One bookie with a saturated journal disk then slows publishing for every topic whose ensemble includes it, and pending writes pile up on all the brokers.

One slow bookie, one shared ack quorum

One producer, three brokers, three bookies on Apache Pulsar

Illustrative

  1. Writes are acknowledged by the bookies as fast as the brokers send them. Pending writes stay low on all three brokers.

  2. Bookie 2's journal disk saturates. The ack quorum needs every bookie in the ensemble, so each write waits for it. Pending writes pile up on all three brokers while bookies 1 and 3 sit idle, and publish latency climbs for every topic.

  3. The ack quorum is now lower than the write quorum, the journal has its own disk, and the slow bookie is replaced. Writes are acknowledged by the fastest bookies again and the brokers drain.

Slow publishes with healthy brokers usually point at BookKeeper, not at Pulsar's serving layer. The fix is settings and disk placement: an ensemble of 3 with a write quorum of 3 and an ack quorum of 2 as the usual starting point, journal and ledger directories on separate devices, bookie auto-recovery checked, and alerts on bookie journal latency. AceMQ reviews each layer on its own.

Our Services

Apache Pulsar Consulting & Services

AceMQ runs five Pulsar service lines: broker and BookKeeper architecture, performance tuning across both layers, migration from Kafka or RabbitMQ, geo-replication with managed operations, and a health check. A senior engineer leads each one, and any of them can roll into 24/7 support.

  • 01

    Multi-Layer Architecture Design

    Pulsar's broker/BookKeeper separation is its key architectural differentiator from Kafka. We size and scale each layer independently, the way Pulsar is designed to run.

    • Broker and BookKeeper (bookie) layer separation design, sized independently for compute vs. storage scaling
    • Namespace and tenant architecture for platform teams serving multiple internal customers on shared infrastructure
    • Topic partitioning and subscription-type selection (exclusive, shared, failover, key-shared) matched to your consumption pattern
    • ZooKeeper metadata store sizing and quorum configuration for cluster coordination
  • 02

    Broker & BookKeeper Performance Tuning

    Latency and throughput problems in Pulsar often live in the BookKeeper layer, not the broker. We tune both independently.

    • Broker-side caching and dispatch throttling tuning to reduce consumer-facing latency
    • BookKeeper journal and ledger disk separation for write-latency isolation from read throughput
    • Managed ledger configuration (ensemble size, write quorum, ack quorum) tuning for durability vs. latency tradeoffs
    • Producer-side batching and compression tuning for high-throughput topics
  • 03

    Migration from Kafka or RabbitMQ

    Pulsar's multi-layer model requires genuinely different operational thinking than Kafka or RabbitMQ. We're upfront about the learning curve before you commit to it.

    • Topic and consumer-group model mapping from Kafka partitions or RabbitMQ queues to Pulsar's subscription model
    • Honest operational learning-curve assessment: BookKeeper adds a storage layer your team will need to learn to operate
    • Kafka-on-Pulsar (KoP) protocol handler evaluation for teams wanting to preserve existing Kafka clients during transition
    • Phased cutover plan with parallel-run validation before decommissioning the legacy broker
  • 04

    Geo-Replication & Managed Operations

    Pulsar's native geo-replication and tiered storage are two of its strongest capabilities — and two of the easiest to misconfigure without hands-on experience.

    • Geo-replication architecture design for multi-region deployments with independent regional failure domains
    • Tiered storage configuration to offload cold ledger data to cheap object storage for effectively infinite retention
    • 24/7 incident response for bookie disk failures, under-replicated ledgers, and broker unloading events
    • Pulsar Functions architecture design for lightweight stream processing without a separate compute cluster
  • 05

    Pulsar Cluster Health Check

    A structured review of your broker and BookKeeper configuration — delivered as a written report your team can act on.

    • Broker and BookKeeper cluster configuration review against production hardening recommendations
    • Namespace and tenant isolation audit for noisy-neighbor risk across shared clusters
    • Ledger under-replication and disk headroom review across the BookKeeper ensemble
    • Written report with prioritized remediation covering durability, multi-tenancy isolation, and upgrade risk
  • 15 MIN SLA

    24/7 Apache Pulsar Support

    Named senior engineers on your account — 15-minute emergency response, no ticket routing, no junior triage.

    • 15-minute emergency response SLA
    • Named engineer, zero cold-start
    • Proactive CVE & health monitoring
    • Quarterly deployment reviews
    Compare the four Apache Pulsar support tiers

Want AceMQ to take this off your team's plate? Tell us about your Apache Pulsar estate.

Contact Us

24/7 Support

Apache Pulsar Support When It Matters Most

AceMQ Pulsar support gives you named senior engineers and a 15-minute first response when production is down, 24/7. Lower severities get 1-hour, 4-hour and next-business-day responses. The same response times cover the broker layer, the BookKeeper layer and the metadata store.

  1. 15 minfirst responseEmergencyProduction down, messages not flowing, queue manager failure
  2. 1 hourfirst responseCriticalSevere degradation, high error rates, approaching capacity
  3. 4 hoursfirst responseHighPerformance issues, configuration problems, non-critical failures
  4. Next Dayfirst responseStandardQuestions, guidance, best practices, non-urgent improvements

P1 escalation path

A replay of one P1, from the first page to the written root-cause analysis

SLA 15:00
T+Elapsed15:00
Engineer on your bridge

15-minute P1 response, 24/7.
A response time, not a resolution time.

  1. T+00:00

    P1 opened, on-call engineer paged

    Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.

    Paged
  2. T+15:00

    Senior engineer on your bridge

    A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.

    Live
  3. T+30:00

    Specialists across the stack join

    When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.

    If needed
  4. After

    Written root-cause analysis

    Root cause, the fix applied and the prevention steps, delivered after every P1.

    Every P1

How Our Support Actually Works

Beyond SLAs — the model behind senior-only, zero-cold-start expert access.

  • Named Engineers on Your Account

    Every ticket is handled by a senior SME assigned to your account — not a pool of anonymous agents. Zero cold-start. No re-explaining your environment.

  • Live Escalation on Any Ticket

    Any ticket can be escalated to a live session with your named engineer via calendar booking. No gatekeeping, no approval required — direct access, always.

  • Proactive Risk Mitigation

    Quarterly health checks on your deployment plus shared intelligence from 50+ support customers — we surface risks before they reach production.

  • Critical Bug & CVE Intelligence

    Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.

Compare Apache Pulsar support plans

How It Works

What actually happens next

A Pulsar engagement runs in four stages: a cluster and BookKeeper assessment of 1 to 2 weeks, written findings within a week, changes made with your engineers, then a handover with runbooks. Each stage ends in writing, split between what belongs to the broker layer and what belongs to storage.

1–2 weeks

Cluster and BookKeeper assessment

We review broker and bookie sizing, ledger and topic retention, namespace policies, subscription types, bundle distribution and tiered storage configuration — treating the broker layer and the BookKeeper layer as the separate systems they are.

Within a week

Written findings and plan

Prioritised findings with the reasoning attached, clearly split between what belongs to the broker layer and what belongs to storage.

Scoped per engagement

Implementation alongside your team

We change namespace policies, retention, subscription patterns and bookie capacity with your engineers rather than around them. Every change is staged and reversible.

Ongoing

Handover and optional cover

Runbooks for backlog recovery, bookie replacement and geo-replication failover, plus 24/7 support with a 15-minute emergency SLA if you want it.

  • Written findings before any change
  • Every change staged and reversible
  • Your engineers in the room
  • You keep the runbooks
  • Ad hoc engagements or an annual partnership

A senior engineer, not an SDR. No sales sequence attached.

Customer Success

Real Apache Pulsar Results

Pulsar work from AceMQ: a BookKeeper I/O remediation, backlog quota support, a multi-tenancy design and a cluster sizing assessment. Each card links to the full write-up: the environment, what AceMQ diagnosed or changed, and the result.

1 / 4 case studies

All use cases

Solutions

Every way AceMQ works with Apache Pulsar.

AceMQ covers Pulsar end to end: broker and BookKeeper consulting and Kafka migrations, 24/7 support and incident management, proactive monitoring, managed clusters on your infrastructure or on AceMQ's, support for releases the community no longer patches, and a fixed-price health check.

Projects

Build, fix or move Apache Pulsar

Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.

Support and managed services

Keep Apache Pulsar running

Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running Apache Pulsar for you.

Compare the four Apache Pulsar support tiers

Side by side

Apache Pulsar vs Apache Kafka: what changes if you move?

Pulsar and Kafka both move events at scale, but Pulsar splits serving from storage: stateless brokers on top, BookKeeper bookies underneath. That changes how you scale, share work and replicate across regions, and it adds a layer your team has to run. Each row below answers one question about the move.

Apache Kafka compared with Apache Pulsar on storage, scaling, consumer model, geo-replication, coordination and migration work
QuestionApache KafkaApache Pulsar
Where is the data stored?On the brokers, in partition logs.In BookKeeper ledgers on separate bookies. Brokers serve topics and keep no data of their own.
How do you scale?Add brokers, then move partitions, which copies data.Add brokers or bookies independently. Topic ownership moves between brokers by bundle without copying data.
How do consumers share work?A consumer group, with partitions assigned to members.Four subscription types: Exclusive, Failover, Shared and Key_Shared. A Shared subscription can have more consumers than partitions.
How is geo-replication done?With a separate tool, such as MirrorMaker 2 or a vendor product.Built into the brokers and switched on per namespace or topic.
What coordinates the cluster?KRaft controllers on Kafka 4.x.A metadata store, ZooKeeper unless another store is configured, in addition to the brokers and bookies.
What does a move involve?Nothing, if Kafka fits the workload.Mapping topics and groups to subscriptions, learning to run BookKeeper, optionally Kafka-on-Pulsar for the client transition, and a parallel run before cutover.

For the full decision, read Kafka vs Pulsar: architecture, operations and which to choose. For who supports a self-managed cluster, read Apache Pulsar support options: community, vendor or independent.

Not sure which option fits? A senior Apache Pulsar engineer will scope it with you.

Contact Us

One partner, not five

We Support Your Entire Tech Stack

Apache Pulsar rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.

Messaging & Streaming

Databases & Caching

Search & Analytics

Lakehouse & Compute

Observability & Monitoring

Data Integration

Cloud & Containers

API Management

VMware Tanzu

See all 51 technologies we supportShow fewer

Guides, articles and comparisons

Go deeper on Apache Pulsar.

Guides from AceMQ engineers on who supports Pulsar, how it compares with Kafka, and the AceMQ services for the Kafka, Redpanda and Flink estates that usually run next to it.

Related services

Ready to talk Apache Pulsar? Get a quote or send us a message.

Contact Us

FAQs

Apache Pulsar Questions Answered

Eight answers on Pulsar from AceMQ: why it is harder to run than Kafka, supported versions, who answers when a cluster fails, how an engagement starts, working with your team, throttled producers, Kafka migration, and managed versus self-run.

Still have questions about Apache Pulsar? Email an Expert

What makes Pulsar harder to operate than Kafka?

Pulsar runs three layers instead of one: stateless brokers, BookKeeper bookies that store the data, and a metadata store. Each fails in its own way and needs its own monitoring. Teams that run it like Kafka often look at the broker when the cause is a bookie disk or the metadata store, so AceMQ diagnoses both layers as standard.

Which Apache Pulsar versions are supported, and when do they reach end of life?

Apache Pulsar ships an LTS release every 18 months, with 24 months of active support and 36 months of security support. Feature releases get 6 months. As of 19 October 2026, 5.0 LTS runs to October 2029, 4.0 LTS gets security fixes until 21 October 2027, and 3.0 LTS security support ended on 2 May 2026.

Who answers when a Pulsar cluster fails in production, and how fast?

A named AceMQ senior engineer answers within 15 minutes, 24/7, when a Pulsar broker, bookie or metadata store failure stops production. Lower severities get a first response within 1 hour, 4 hours or the next business day. The engineer who takes the first call stays on the case, and a written root-cause analysis follows every P1.

How does a Pulsar consulting engagement with AceMQ start?

An AceMQ Pulsar engagement starts with a free consultation with a senior engineer, booked in our reply within 1 hour. Next comes a cluster and BookKeeper assessment of 1 to 2 weeks covering broker and bookie sizing, ledger and topic retention, namespace policies, subscription types and bundle distribution. Written findings follow within a week, before anything changes.

Can a Pulsar engineer work alongside our in-house team?

Yes. AceMQ assigns a named senior engineer from its team of 11+ who works with your engineers rather than around them, changing namespace policies, retention, subscription patterns and bookie capacity together. Every change is staged and reversible. You keep the runbooks for backlog recovery, bookie replacement and geo-replication failover.

Why are our Pulsar producers suddenly throttled or blocked?

Almost always a backlog quota. When a subscription's backlog reaches the quota, the policy decides what happens: producer_request_hold holds producers, producer_exception rejects their sends, and consumer_backlog_eviction drops the oldest messages. AceMQ checks which policy is set and where it is set, because namespace and topic levels override each other.

Is migrating from Kafka to Pulsar difficult?

Mapping topics and consumer groups to Pulsar's subscription model is usually the easier part. The harder part is operational: your team must learn to run and monitor BookKeeper, which has no Kafka equivalent. Kafka-on-Pulsar can ease the client transition. AceMQ says plainly when Pulsar does not fit the workload.

Should we run Pulsar ourselves, use a vendor's cloud, or buy managed Pulsar from AceMQ?

It depends on who should hold the pager and where the data may live. Self-run suits teams that already operate BookKeeper well. A vendor cloud such as StreamNative removes infrastructure work but not namespace design or backlog policy. Managed Pulsar from AceMQ runs inside your own account or data centre, or on AceMQ infrastructure, as Tiers 3 and 4 of the same support ladder.

Can we work with AceMQ on Apache Pulsar without a long contract?

Yes. AceMQ works on Apache Pulsar in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.

How much does AceMQ Apache Pulsar support or consulting cost?

Every AceMQ proposal is tailored to your requirements: your Apache Pulsar environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how Apache Pulsar is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.

Let's talk

Ready to Get the Most Out of Pulsar's Architecture?

Whether you need emergency support, a health check, a Kafka migration, or ongoing managed operations — AceMQ staffs every engagement with a named senior engineer. Quote requests answered within 1 hour.

A senior Pulsar engineer, not a sales queueAbout your brokers and bookies, not a pitch deckQuote requests answered within 1 hour

Production incident right now?Email an Apache Pulsar Architect

Get in Touch

Talk to an Apache Pulsar Expert

Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.

305-204-2607
info@acemq.com
66 W. Flagler St. 9th Floor
Miami, FL 33130

Prefer to talk now? Call us directly or use the consultation tab to find a time that works.

We respond within 1 hour.

Pick a time that works — no pressure, no pitch. Just 30 minutes with an expert.

We respond within 1 hour.