● Beta — KubeEra is in active development. Profiles are live; AI-perception measurement is rolling out.
KubeEra
A

Apache Zookeeper

Orchestration
Open source · Apache-2.0

Apache ZooKeeper is a centralized coordination service for distributed systems.

updated 2026-07-01

What it is

Apache ZooKeeper is a centralized coordination service for distributed systems. It provides a hierarchical key-value store (znodes, structured like a filesystem) with strong consistency guarantees, used for leader election, distributed locking, configuration management, and service discovery. It's not a database and not a message queue — it's the thing other distributed systems lean on to agree on shared state. Kafka (pre-KRaft), Hadoop, HBase, and Solr have all historically depended on it for cluster coordination.

Who builds it and why

ZooKeeper is an Apache Software Foundation project, originally spun out of Yahoo Research. It's maintained by a broad set of committers tied to the Hadoop/big-data ecosystem rather than a single vendor. 338 contributors on GitHub and 12,780 stars indicate a large but mature contributor base — this is not a project attracting a wave of new committers, it's one being kept alive and hardened by people who run it in production and depend on it for other Apache projects. The motivation is straightforward: distributed coordination is a hard, well-understood problem, and ZooKeeper solved it early enough that ripping it out of dependent systems (see Kafka's KRaft migration) takes years.

Production readiness signal

ZooKeeper has been production-hardened for over a decade — it predates most of the current "cloud native" tooling landscape. The commit cadence (last commit 2026-06-25) shows the project is still actively maintained, not abandoned, despite its ecosystem role shrinking. License is Apache-2.0, no vendor lock-in. CNCF maturity level is not publicly available — ZooKeeper predates CNCF and was never part of that foundation's landscape, so don't expect a graduation badge here. Latest release and founding date are not publicly available in the data provided; check the Apache ZooKeeper release page directly before deploying, since version-to-version behavior (especially around dynamic reconfiguration and TLS) has changed meaningfully over the years.

Who should use this

  • Teams already running systems that hard-depend on ZooKeeper (older Kafka clusters, HBase, Hadoop, Solr/SolrCloud, Pulsar's older BookKeeper metadata store) and don't have a migration path yet.
  • Teams building their own distributed system that needs proven leader-election/config-management primitives and want an operationally battle-tested option over rolling their own Raft implementation.
  • Environments where JVM operations expertise already exists in-house — running ZooKeeper well means understanding JVM GC tuning, disk I/O for its write-ahead log, and ensemble sizing.

Who should NOT use this

  • New Kafka deployments — Kafka has moved to KRaft (Raft-based, no ZooKeeper) as of 3.x/4.x, and running ZK alongside Kafka today is adding operational debt for no reason.
  • Teams looking for a general-purpose distributed cache or database — ZooKeeper znodes are capped in size (default 1MB) and it's not designed for high-throughput reads/writes of business data.
  • Small teams without dedicated ops capacity — running a ZK ensemble correctly (odd number of nodes, network partition tolerance, proper disk isolation for logs) is nontrivial operational overhead for something that, if misconfigured, silently causes split-brain issues in every system depending on it.
  • Anyone starting a new project today needing coordination primitives — etcd or built-in Raft implementations are generally simpler to operate and have better cloud-native tooling integration.

Alternatives

  • etcd — CNCF graduated, gRPC-based, the default choice for new Kubernetes-adjacent coordination needs; simpler operational model.
  • Consul — HashiCorp's coordination/service-discovery tool, adds built-in service mesh and health-checking on top of KV coordination.
  • Kafka KRaft (Raft consensus built into Kafka) — not a general replacement, but relevant if your only reason for running ZooKeeper is Kafka.

Pricing

Fully open source under Apache-2.0. No paid tier, no vendor. Cost is entirely operational — infrastructure and the engineering time to run and tune an ensemble correctly.

Frequently asked

What is Apache Zookeeper?+
Apache ZooKeeper is a centralized coordination service for distributed systems. It provides a hierarchical key-value store (znodes, structured like a filesystem) with strong consistency guarantees, used for leader election, distributed locking, configuration management, and service discovery.
Who builds Apache Zookeeper?+
ZooKeeper is an Apache Software Foundation project, originally spun out of Yahoo Research. It's maintained by a broad set of committers tied to the Hadoop/big-data ecosystem rather than a single vendor.
Is Apache Zookeeper production ready?+
ZooKeeper has been production-hardened for over a decade — it predates most of the current "cloud native" tooling landscape. The commit cadence (last commit 2026-06-25) shows the project is still actively maintained, not abandoned, despite its ecosystem role shrinking. License is Apache-2.0, no vendor lock-in.
Who should use Apache Zookeeper?+
Teams already running systems that hard-depend on ZooKeeper (older Kafka clusters, HBase, Hadoop, Solr/SolrCloud, Pulsar's older BookKeeper metadata store) and don't have a migration path yet.
Who should not use Apache Zookeeper?+
New Kafka deployments — Kafka has moved to KRaft (Raft-based, no ZooKeeper) as of 3.x/4.x, and running ZK alongside Kafka today is adding operational debt for no reason.
What are the alternatives to Apache Zookeeper?+
etcd — CNCF graduated, gRPC-based, the default choice for new Kubernetes-adjacent coordination needs; simpler operational model. Consul — HashiCorp's coordination/service-discovery tool, adds built-in service mesh and health-checking on top of KV coordination.
How much does Apache Zookeeper cost?+
Fully open source under Apache-2.0. No paid tier, no vendor. Cost is entirely operational — infrastructure and the engineering time to run and tune an ensemble correctly.