[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fg3pykbeieixb":3},{"code":4,"message":5,"data":6,"timestamp":45},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":27,"summary_md":28,"topic":29,"github_topics":32,"license":39,"homepage":40,"updated_at":41,"history":42},"apache\u002Fpulsar",6,"Apache Pulsar - distributed pub-sub messaging system","Java",15354,3776,2,3771,[16,22],{"id":17,"title":18,"points":19,"comments":20,"posted_at":21},23816732,"Pulsar – an open-source distributed pub-sub messaging platform",155,58,"2020-07-13",{"id":23,"title":24,"points":13,"comments":25,"posted_at":26},18881847,"Apache Pulsar – distributed pub-sub messaging system",0,"2019-01-11","A multi-tenant pub-sub and streaming platform for teams that need queueing, event replay and geo-replication in one cluster.","Apache Pulsar is worth considering when you need one messaging system to cover both work queues and event streaming, and you accept running a JVM-based cluster with its own storage layer. It is not a drop-in for a small project; the operational surface is the main decision point, not the feature list.\n\n## The problem\n\nA team starts with a queue for background jobs, then adds a separate log for event replay, then needs cross-region copies of some topics. Each system brings its own client libraries, retention rules and administration. Pulsar consolidates these into one cluster: producers publish to topics, consumers either share a subscription (queue semantics) or each read the full stream, and the broker tracks consumer cursor positions so replay is a configuration choice rather than a rebuild. The result is one provisioning API and one tenancy model instead of several.\n\n## What's different\n\nPulsar separates serving from storage. Brokers handle connections, topic ownership and dispatch, while durable data sits in BookKeeper bookies; the README also lists geo replication, transparent partitioned topics, batching and a load balancer as core features [project instructions](https:\u002F\u002Fgithub.com\u002Fapache\u002Fpulsar\u002Fblob\u002Fmaster\u002FREADME.md). In practice this means a broker is mostly a caching and routing layer, so expanding capacity for connections and capacity for storage can be planned separately. Multi-tenancy, authentication, authorization and quotas are designed in from the start, which matters if you host messaging for several teams or customers rather than running one application's bus.\n\nThe trade-off is that the boundary between broker and storage is not free. A 2020 HN commenter noted the appeal of stateless brokers but argued that the surrounding JVM dependencies create administration overhead for companies that are not operating at very large scale [comment](https:\u002F\u002Fnews.ycombinator.com\u002Fitem?id=23819050:); a reply pointed out that BookKeeper nodes remain stateful, so replacing one still involves data redistribution [reply](https:\u002F\u002Fnews.ycombinator.com\u002Fitem?id=23819295:). Treat that as an architectural warning about where the operational work moves, not as a verdict on the current release.\n\n## Who should try it\n\nGood fit: a platform team already running Kubernetes and expecting multiple tenants, durable replay, or geo-replication, where one system with queue and stream semantics reduces the number of moving parts to operate. Also a fit for organizations that need per-topic retention and cursor management without building it themselves.\n\nPoor fit: a single application that just needs a lightweight job queue or a small pub-sub bus, or a team without someone who can own a stateful storage tier. A 2020 commenter said they prefer RabbitMQ in production and Redis for small projects [comment](https:\u002F\u002Fnews.ycombinator.com\u002Fitem?id=23817629:); that reflects a different scale and operational appetite. Starting from the Docker image [container image](https:\u002F\u002Fhub.docker.com\u002Fr\u002Fapachepulsar\u002Fpulsar) or a Helm chart [Helm chart](https:\u002F\u002Fgithub.com\u002Fapache\u002Fpulsar-helm-chart) is documented, but those paths change installation, not the need to understand the broker\u002Fbookie split.\n\n## Requirements and limitations\n\nVersion and JDK are coupled: master targets JDK 21, 25 or 26, the 4.0+ line targets JDK 21, and older lines need JDK 17 or below [version table](https:\u002F\u002Fgithub.com\u002Fapache\u002Fpulsar\u002Fblob\u002Fmaster\u002FREADME.md). Upgrading Pulsar therefore often means upgrading the runtime first. Building needs a JDK and zip, plus the documented build tooling; the Gradle wrapper removes a separate Gradle install [setup guide](https:\u002F\u002Fpulsar.apache.org\u002Fcontribute\u002Fsetup-buildtools\u002F).\n\nOngoing upkeep is the larger cost. You are responsible for broker and BookKeeper capacity, topic and subscription cleanup, quota policy and client-version compatibility across the separate language clients [client list](https:\u002F\u002Fgithub.com\u002Fapache\u002Fpulsar\u002Fblob\u002Fmaster\u002FREADME.md). The README points to other repositories for connectors, adapters and clients, so those components do not necessarily move in lockstep with the core. There is no one-command way around planning for stateful storage nodes and their data movement.\n\n## HotRepo's take\n\nHotRepo recorded one daily-board appearance on 2026-10-25 with 15,353 stars and +2 that day; the single dated snapshot cannot establish whether interest is rising, fading or sustained. The older HN thread (2020) shows discussion volume, not current consensus. Before committing, verify the JDK line for the exact release you plan to run and read the broker\u002FBookKeeper operational guidance, since that architecture determines who must own the cluster.",{"slug":30,"name":31},"devops","DevOps & Self-hosting",[33,34,35,36,37,38],"event-streaming","messaging","pubsub","pulsar","queuing","streaming","Apache-2.0","https:\u002F\u002Fpulsar.apache.org\u002F","2026-10-25T11:06:14Z",[43],{"date":44,"stars":11,"stars_gained":13},"2026-10-25",1792967925]