Apache Kafka vs Apache Pulsar: which to choose

Apache Kafka vs Apache Pulsar: when to choose each

Choose Apache Kafka when one organization runs event pipelines and wants a large connector ecosystem around a single cluster. Choose Apache Pulsar when a platform team serves many internal tenants and needs storage to scale independently of brokers. Both are Apache-2.0 licensed, so the decision turns on operating model and fit, not license cost. Start by counting how many teams will share the cluster. Kafka's partitions live on the brokers that serve them, so growing storage usually means growing broker capacity. Pulsar separates stateless brokers from Apache BookKeeper bookies, so storage grows by adding bookies without changing broker count. Confirm which of those two scaling paths your capacity plan actually needs.

Next, check what already exists. Kafka Connect, the Kafka client libraries and the tooling your teams use are a large share of the switching cost, and Pulsar's client and connector model differs from them. Count the Kafka clients and connectors in production today. Then review the in-house skills. Running Kafka means operating brokers, controllers and the KRaft metadata layer, while Pulsar adds BookKeeper and a metadata store choice (Oxia, ZooKeeper or RocksDB, per the Pulsar architecture overview), so each design needs its own operators. Ask which team will carry the pager and whether it already runs either system.

Finally, match the release policy to your upgrade capacity. Pulsar publishes an LTS release every 18 months with 24 months of active support and 36 months of security support, while Kafka supports the last three releases for rolling upgrades. Check the current Pulsar release policy and the Kafka downloads page against your change calendar, and confirm the support window your auditors and internal standards will accept before committing.

How each platform is built and what that means for operations

Kafka and Pulsar split the same jobs differently: routing, storage, and cluster metadata. Each card below names one component, the sizing and maintenance work it creates, and the question to answer before committing. Read them together, because scaling, patching, and recovery decisions in one component affect the others.

Kafka brokers hold partitions on local disks

In Apache Kafka, each partition log is written to the local disks of the broker that leads it, and follower replicas on other brokers copy it. The operations team must size broker disk for retention and replication factor, watch for under-replicated partitions, and plan disk growth per broker. Adding storage usually means adding brokers and rebalancing partitions, so compute and storage capacity grow together. Ask how long a broker replacement and partition reassignment take on your hardware before you set retention targets.

KRaft controllers replace ZooKeeper

Since Kafka 4.0, cluster metadata is kept in a KRaft controller quorum, and ZooKeeper mode has been removed. Operators must decide whether controllers run combined with brokers or on dedicated nodes, then keep the quorum healthy during every patch cycle. The Kafka upgrade notes recommend that KRaft clusters older than 3.3.x move to 3.9.x before moving to 4.x. Confirm your migration path and controller count before you plan maintenance windows.

Pulsar brokers stay stateless

Pulsar brokers route messages but do not hold topic data, so a broker can be replaced without moving stored segments. The operations team sizes brokers for connection count, throughput, and topic load, and scales them on a schedule separate from storage. Patching brokers mainly affects client connections and topic ownership, not stored data. Check that your load balancer, client reconnect behavior, and failover tests meet your recovery targets before relying on this model.

BookKeeper bookies hold the write-ahead log

Apache BookKeeper bookies persist messages as a distributed write-ahead log, so durable storage sits in a tier separate from the brokers. Storage capacity grows by adding bookies independently of brokers, which lets the team add disk without changing routing capacity. The team must size bookie disks and journal placement, monitor disk and ledger health, and plan bookie decommissioning. Ask how your replication and acknowledgment settings map to your durability target before you size the tier.

Metadata store choice sets dependencies

Pulsar's metadata store can be Oxia, which the project recommends for new clusters, or ZooKeeper, or RocksDB. The choice determines which system the operations team must back up, patch, and monitor alongside brokers and bookies. Existing ZooKeeper-based deployments carry that dependency forward, so review the migration path before committing to a release. Confirm which options your target Pulsar version supports and how metadata recovery is tested in your environment.

Which platform fits which scenario

This table maps common team situations to the platform that fits them better, and names the condition under which the other platform would be stronger. Read each row as a starting point, then check the conditions against your own traffic, team skills and topology.

Scenario	Better fit	Why
Single-team event pipeline	Apache Kafka	One team owning topics, brokers and clients keeps the broker-stored partition model simple to reason about. Pulsar becomes the stronger choice if the team expects to add many isolated tenants later.
Shared platform serving many business units	Apache Pulsar	Multi-tenancy, authentication, authorization and quotas are part of its design. Kafka can serve many units too, but isolation is usually built by convention and tooling, so confirm it against your own requirements.
Existing Kafka clients and Kafka Connect pipelines	Apache Kafka	Kafka Connect runs in standalone or distributed mode and is managed through a REST API, so existing connectors and clients carry over directly. Pulsar is the stronger choice only if you are starting from no Kafka estate.
Geo-replicated deployments	Apache Pulsar	Geo-replication is a listed core feature. Kafka also supports cross-cluster mirroring, so confirm the replication topology, failover behavior and tooling you need before deciding.
Storage that must grow faster than compute	Apache Pulsar	Storage grows by adding BookKeeper bookies independently of brokers. In Kafka, broker-stored partitions tie storage growth to broker capacity, so Kafka is the stronger choice when storage and compute scale together.
Teams with no streaming operations skills	Apache Kafka	Kafka has a single core component type in KRaft mode, and most teams find its topology easier to start with. Pulsar adds BookKeeper and a metadata store to run, so Pulsar suits teams with the skills to operate those layers.
Teams that need a long-term support window with a defined policy	Apache Pulsar	Pulsar publishes an LTS every 18 months with 24 months of active and 36 months of security support. Confirm the Kafka support windows on its downloads page before you compare lifecycles.

How multi-tenancy and geo-replication change the decision

Pulsar is designed to run as a hosted service, with multi-tenancy, authentication, authorization, quotas and optional hardware isolation built into the platform. That matters when one platform team serves several internal business units, or a provider serves outside customers, and each tenant needs its own access rules and capacity limits on shared brokers and bookies. If you run one product team's event bus, those controls may be more than you need, and the tenancy model adds configuration you must own and review. Before you choose Pulsar for shared use, confirm which tenant boundaries your organization requires, whether a tenant must have dedicated hardware, and who sets and audits quotas. Then prove those settings in a staging cluster before you promise isolation to any business unit.

Kafka's access model works differently. In KRaft clusters, the StandardAuthorizer stores ACLs in the cluster metadata log, and authentication is optional, so you choose the SASL mechanism and TLS settings per listener. The default to check first is the no-ACL rule: resources without an ACL are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Leaving that key true during a migration can quietly open topics meant to be locked down, while leaving it unset can break clients that were never granted access. Before go-live, inventory every topic, consumer group and cluster resource, map each principal to its operations, and test that an unlisted client is denied. The Kafka authorization documentation covers the full ACL model.

Both platforms replicate across sites, but the operating model differs. Pulsar lists geo-replication among its core features, so cross-cluster replication is part of how the platform is meant to be run. Kafka handles cross-cluster copying through mirroring between separate clusters, described in its geo-replication documentation. Your choice depends on your topology: how many sites you run, which direction data flows, whether consumers must resume at the right position after failover, and how much lag or duplication your business can accept. Confirm with each vendor's documentation for your exact versions what must be configured on each side and how failover is handled. Then run a scheduled failover test that promotes the secondary site, produces and consumes traffic, and records what was lost or duplicated, and write the results into your recovery runbook.

Side-by-side capability and licensing facts

This table sets the licensing, architecture, security and release facts for Apache Kafka and Apache Pulsar side by side. Read the rows on storage, metadata and release policy first, since they drive most of the operating difference, then confirm the Pulsar security details against its documentation before you shortlist either platform.

Capability	Apache Kafka	Apache Pulsar
License	Apache-2.0. The project itself offers no paid edition.	Apache-2.0, an Apache Software Foundation project.
Storage model	Partitions are stored on the brokers that lead them, so broker disks hold the log.	Stateless brokers route messages while Apache BookKeeper bookies persist them as a distributed write-ahead log.
Metadata layer	KRaft only since 4.0. ZooKeeper mode has been removed.	Oxia (recommended for new clusters), ZooKeeper or RocksDB.
Multi-tenancy	Handled through topic naming, ACLs and quotas that you design and maintain yourself.	Built in, with tenants, authentication, authorization, quotas and optional hardware isolation, per the project README.
Geo-replication	Supported through cross-cluster mirroring; confirm the tooling and topology in the Kafka geo-replication documentation.	Supported as a core feature; confirm the replication configuration in the Pulsar documentation.
Client authentication	SSL/TLS encryption plus SASL: GSSAPI (Kerberos), PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER. Security is optional.	Authentication and authorization are supported; confirm the supported mechanisms and TLS setup in the Pulsar documentation.
Java requirement	Java 17 for brokers, Kafka Connect and tools since Kafka 4.0. Clients and Streams need Java 11 or later.	Confirm the JVM version for your Pulsar release in the Pulsar documentation.
Supported releases	4.3.1 (June 25, 2026), 4.2.2 (September 29, 2026) and 4.1.2 (March 17, 2026).	Pulsar 5.0 LTS (October 5, 2026) and Pulsar 4.0 LTS (October 21, 2024), with support dates in the release policy.
REST administration	Kafka Connect exposes a REST API; broker administration uses the Kafka admin tools and clients.	REST API for provisioning and administration of topics and tenants.

License, editions and release policy for each platform

Apache Kafka is an Apache Software Foundation project released under the Apache License 2.0 (SPDX: Apache-2.0). The project itself offers no paid edition, so every feature in the open-source release is available without a license key. Commercial support, if you want it, comes from third parties, and what they cover is set in their own contracts. The Kafka downloads page lists 4.3.1 (June 25, 2026), 4.2.2 (September 29, 2026) and 4.1.2 (March 17, 2026) as supported releases, and earlier versions are archived.

Permissive license: Apache-2.0 places no paid-edition gate on the core broker, Kafka Connect or the tools in the project.
Release cadence: The project aims for three releases a year, one every four months.
Supported lines: 4.3.1, 4.2.2 and 4.1.2 are the releases that receive bugfix work.
Rolling upgrades: The time-based release plan supports rolling upgrades from each release in the past year, which means the last three releases, to the latest version.
Bugfix releases: These are made as needed, and only for supported releases.

Confirm with your legal team which Kafka-related components and connectors you plan to use, since third-party connectors carry their own licenses.

Moving a workload from Kafka to Pulsar, or back

This sequence moves a streaming workload between Kafka and Pulsar without a single cutover, so producers and consumers can be verified on both platforms before the old cluster is retired. It produces a documented inventory, a tested parallel pipeline and a decommissioned source cluster with a clear record of what was rebuilt.

Confirm client library compatibility first
Before any inventory work, the platform engineering team confirms with each client library owner whether the language clients in use can produce and consume against the target platform, and which features they depend on, such as transactions, compacted topics, consumer group semantics, schema registry use and specific partitioner behavior. Pulsar has its own client libraries and a Kafka-compatible option, so confirm which path your teams would use and what it does not cover. Also confirm the Kafka version you run, since Kafka 4.x requires Java 17 for brokers and Kafka Connect, and check the supported Kafka releases on the downloads page before choosing a target. The step is done when every client has a written compatibility answer signed off by its owner.
Inventory topics, clients, groups and connectors
The platform team lists every topic with its partition count, retention settings, compaction policy and producer and consumer applications, plus every consumer group and its committed offsets. The same inventory covers schemas, Kafka Connect source and sink connectors with their configuration, and the ACLs that control access, which in KRaft clusters live in the cluster metadata log. Record which resources have no ACL today, because the default behavior for those resources affects what must be rebuilt on the target. The output is a single inventory register owned by the workload team, reviewed by security and checked against the running cluster so nothing is missed.
Map partitions and retention to Pulsar
The architecture team maps each Kafka topic to a Pulsar topic and decides how partitioned topics, ordering keys and retention translate. Kafka keeps partitions on the broker disks, while Pulsar stores messages in BookKeeper ledgers on bookies that scale separately from brokers, so retention and storage sizing must be recalculated against bookie capacity rather than copied from Kafka settings. Document where ordering guarantees depend on a single partition and whether that holds under Pulsar's partitioned topic model. The output is a mapping table with a retention and ordering decision for each topic, reviewed by the owners of the consuming applications.
Rebuild authorization, monitoring and connectors
Authorization is rebuilt on the target instead of copied, because Kafka ACLs do not map one to one onto Pulsar's tenant, namespace and authorization settings. The team recreates access rules, quotas and authentication for each tenant, rebuilds each connector on the target platform or its equivalent bridge, and replaces broker metrics, alerts and dashboards with the target's own. Security reviews the new access model against the inventory from the earlier step. The step is complete when every access rule in the register has a matching target rule, every connector has a tested replacement and alerts fire on test failures.
Run a parallel pipeline with dual production
Producers are changed to write to both clusters for a defined validation period, while consumers continue reading from the source. The team compares message counts, ordering, payload checksums and schema validation between the two paths for each topic, and records any gaps. Data is replayed or bridged only for the window needed to validate the pipeline, since historical data does not move automatically in a parallel run. The output is a validation report per topic that shows matching counts and no unexplained differences, approved by the workload owner before consumers move.
Move consumers and verify offsets
Consumers are switched one consumer group at a time, starting with the least critical workload. For each group, the team records the last committed Kafka offset, starts the new consumer from the matching position in the target, and confirms that no message was skipped or processed twice beyond what the application's idempotency design allows. Duplicate handling and replay behavior are tested explicitly, since offset positions do not carry over between the two systems. The step is done when each group has processed live traffic on the target for a stable period and its owner signs off on the reconciliation.
Decommission the old cluster in controlled stages
Once every producer and consumer runs on the target, the team stops writes to the source, keeps the source readable for a rollback window agreed in advance, and then archives any data the business or auditors require. Connectors, ACLs, credentials and monitoring tied to the old cluster are removed, and the platform's backup and retention jobs are updated. The output is a decommissioning record listing what was archived, where it is stored, who approved removal and which access was revoked. Any retention obligations should be confirmed with compliance before data is deleted.

What drives the running cost of each platform

Kafka and Pulsar both cost money in infrastructure, people, support, upgrades and vendor options, but the shape of that spend differs. The cards below set out who gets paid for each cost, what is one-time and what recurs, and what to put in a quote so the two platforms can be priced on the same scope.

Infrastructure footprint

Kafka keeps partition data on broker disks, so storage grows with brokers, and capacity planning ties disk, network and replication factor together. Pulsar splits the work: stateless brokers route messages while BookKeeper bookies persist them, and storage grows by adding bookies without adding brokers. Ask each vendor or partner for a written sizing of brokers, bookies (for Pulsar), controllers, disks and replication factor for your retention and throughput, and for the extra nodes a metadata store needs.

In-house skills

Kafka operations centre on brokers, KRaft controllers, topic design, client configuration and Kafka Connect. Pulsar adds BookKeeper, ledger and metadata store operations on top of the broker layer, so a Pulsar team usually needs skills in two storage tiers. Staff time is a recurring cost that is easy to omit from quotes. Ask who will run each stack day to day, what training is included, and how many engineers the plan assumes.

Support from vendors and consultants

Both projects are Apache-2.0 with no paid edition from the project itself, so support comes from commercial distributors, managed hosting providers or independent consultants such as DeployOpen, which is paid under a written, fixed-scope agreement. Support is a recurring cost when it is a retainer and a one-time cost when it covers an implementation. Ask for response expectations in writing, who holds on-call duty, and whether incident work is inside or outside the retainer.

Upgrade effort against release policy

Kafka ships roughly three feature releases a year and supports rolling upgrades from each release in the last year to the latest version. Pulsar ships an LTS every 18 months with 24 months of active support and 36 months of security support, plus feature releases every three months. Plan upgrade effort against the policy each project publishes, and ask a partner how many upgrade cycles the contract covers over your planning horizon and who tests client compatibility.

Paid editions and hosted services

Neither Apache Kafka nor Apache Pulsar has a paid edition from its project. Managed or hosted offerings come from separate vendors, and their fees depend on capacity, regions and support tier. Pulsar is designed to run as a hosted service with multi-tenancy and quotas, which can shift cost into platform administration. Ask any vendor for a line-item quote covering compute, storage, data transfer, support level and exit terms, and confirm which features sit behind each tier.

Where Kafka and Pulsar implementations usually run long

Kafka and Pulsar projects tend to run long for different reasons, and the first decision is which Kafka starting point you have. If you run ZooKeeper-era Kafka clusters, the upgrade path is the critical item: Kafka 4.0 supports only KRaft mode and ZooKeeper-based clusters must migrate to KRaft before upgrading to 4.x. The Kafka upgrade notes also recommend that KRaft clusters older than 3.3.x first move to 3.9.x before moving to 4.x. Confirm in writing which version your clusters run today, whether the migration is included in scope, and how many upgrade hops the plan includes. On the Pulsar side, the main early decision is the metadata store. The architecture overview lists Oxia (recommended for new clusters), ZooKeeper and RocksDB, so the choice should be settled before any cluster is built.

Pulsar also adds sizing work that Kafka does not. A Pulsar cluster separates stateless brokers, which route messages, from BookKeeper bookies, which hold persistent storage as a distributed write-ahead log. Storage capacity grows by adding bookies independently of brokers, but that means two capacity models, two scaling runbooks and two sets of monitoring to maintain. Ask for the sizing assumptions in the scope, including retention, throughput and topic counts, and confirm who owns bookie replacement and rebalancing after go-live.

Across both platforms, projects usually slip in the same four places: client migration, schema and access control design, geo-replication testing and monitoring. Client migration takes longer than the broker work because every producer and consumer must be moved and retested. On Kafka, ACL design is stored in the KRaft metadata log under the StandardAuthorizer, and resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true, so access rules need to be planned before cutover. Geo-replication failover should be tested with real failure scenarios, not only configured. Written scope should name the test cases, the monitoring stack and the acceptance criteria for each.

Questions buyers ask before choosing Kafka or Pulsar

What does a Kafka or Pulsar implementation cost, and what drives it?

Neither project charges a license fee, so the cost is the work and the infrastructure. Apache Kafka is Apache-2.0 with no paid edition from the project itself, and Pulsar is also Apache-2.0. Recurring costs are the compute and storage for brokers, plus staff time for upgrades, monitoring and on-call. Pulsar adds a separate BookKeeper tier and a metadata store, so it usually has more components to size, patch and pay for. Implementation cost rises with the number of topics and clients, retention and replay needs, security integration (TLS, SASL mechanisms, ACLs) and the number of connectors or migrations in scope. DeployOpen works from a written scope and does not publish a price list. Ask any partner for a quote that separates one-time build work (design, deployment, hardening, documentation, testing) from recurring items (support retainers, upgrades, capacity). Also ask which cluster sizes and upgrade cadence the quote assumes.

How long does an implementation take, and what changes the timeline?

No duration is supplied for either platform, so treat any single number as a claim to verify against a written scope. The timeline is set by the number of environments, the security baseline, the integration count and how familiar the team is with the platform. For Kafka, the main variables are the KRaft cluster layout, client authentication through SSL or a documented SASL mechanism, ACL design under the StandardAuthorizer and connector work. For Pulsar, add bookie sizing, the choice of metadata store (Oxia is recommended for new clusters) and multi-tenant namespace design. Delays usually come from access requests, approval cycles for network and identity changes and load tests that run late. Ask for milestones with named deliverables and a sign-off gate for each environment, and ask how scope changes after the start date will be priced and scheduled.

What must our team provide during an implementation?

Plan to provide skills, environments, access and sign-off. Skills: at least one person who will own the platform after handover and can read broker, controller or bookie logs and make capacity decisions. Environments: a non-production cluster that matches the target layout, plus the networks, DNS, certificates and compute the platform needs. Access: accounts in your cloud or data center, identity provider or Kerberos setup if you use it, and the privileges to create service principals and ACLs. Sign-off: named approvers for security configuration, data classification, change windows and go-live. DeployOpen implements inside your own infrastructure, so these inputs come from you. Confirm in writing which items the client owns and which the implementation partner owns, and record who approves each one.

Can an in-house team run Kafka or Pulsar without outside help?

Many teams can, provided they accept the ongoing operating load. Kafka 4.0 supports only KRaft mode and removes ZooKeeper, so a Kafka cluster is one system to learn and the upgrade notes give a defined path. Upgrades still need planning: rolling upgrades are supported from each release in the past year to the latest version, and ZooKeeper-based clusters must migrate to KRaft first. Pulsar asks the team to run stateless brokers, BookKeeper bookies and a metadata store, and to understand how each scales. Either platform needs monitoring, backup planning, security configuration and a tested upgrade routine. The deciding question is whether your staff can cover on-call and upgrades continuously. DeployOpen offers implementation, hardening, documentation and retainers for ongoing support and upgrades, so you can run the platform yourselves, buy a retainer, or split the work. Decide this before the build starts.

Which platform suits a small team?

For most small teams with limited operations staff, Kafka usually asks for less to run, though the answer depends on your workload. Broker storage holds the main state, and KRaft removes the separate coordination service. Pulsar separates stateless brokers from BookKeeper bookies and a metadata store, which suits large multi-tenant platforms and independent storage scaling, but it adds roles to monitor and patch. Pulsar is designed to run as a hosted service with multi-tenancy, authentication, quotas and optional hardware isolation, which matters when many teams share one cluster. If a small team needs one event log with a few consumers, Kafka's smaller component set is the simpler starting point. If multi-tenant isolation is required from day one, test Pulsar against that requirement before committing. In either case, have a partner size the first cluster from your actual message volume and retention.

How do LTS policies affect upgrade planning?

Pulsar's policy sets fixed support windows you must plan around. Pulsar ships an LTS release every 18 months, with 24 months of active support and 36 months of security support, and feature releases every three months with six months of support. Pulsar 4.0 LTS has active support until October 21, 2026 and security support until October 21, 2027. Pulsar 5.0 LTS, released October 5, 2026, has active support until October 5, 2028 and security support until October 5, 2029. Kafka works differently: the project aims for a release every four months, lists 4.3.1, 4.2.2 and 4.1.2 as supported releases, and makes bugfix releases only for supported lines. Enter each product's end dates in your upgrade calendar and schedule a test cycle before each one. Pulsar release policy lists the full terms.

Do Kafka clients work with Pulsar?

The supplied facts do not establish that Kafka clients work with Pulsar, so do not assume they will. Kafka's clients are built for Kafka brokers, while Pulsar has its own client libraries, topic model and REST API for administration. Before choosing either platform, list every producer and consumer with its language, client library and any dependence on Kafka-specific behavior such as consumer groups, compacted topics or Kafka Connect connectors. Then check the current Pulsar documentation for any Kafka compatibility option, its supported features and its known gaps. Test each client against a non-production cluster. If you are migrating, plan a dual-run period and a documented rollback path. Ask any implementation partner to include client compatibility testing in the written scope.

How DeployOpen helps choose, implement or migrate

DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Kafka or Pulsar decision, that means working from your own topology, security requirements and operating model before any platform is chosen or installed.

How we scope

Scope covers the workload profile, tenancy model, regions and the ownership of brokers and storage.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Written scope names the Kafka or Pulsar version, the deployment target and the integrations in use.

How we build

Build covers the cluster layout, authentication, authorization and TLS configuration for your environment.
Testing checks replication, failover behavior and client compatibility against your real producers and consumers.
Geo-replication and multi-tenancy designs are validated against the controls your security team requires.

How we hand over

Handover includes architecture documentation, runbooks for upgrades, and the operational evidence your team needs.
Operators receive training on monitoring, capacity changes and incident procedures for the chosen platform.
Documentation records which release line, support window and licensing terms the deployment depends on.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can track vendor release and support windows so upgrade planning stays ahead of end-of-life dates.
Support scope is agreed in writing, so your team knows which changes and incidents are covered.

Apache Kafka vs Apache Pulsar