ZooKeeper vs etcd: Which Coordination Store?
ZooKeeper is a long-established coordination service with watches and ephemeral nodes; etcd is a modern, Raft-backed key-value store with a simple HTTP/gRPC API.
ZooKeeper, built on ZAB consensus, offers hierarchical znodes, watches, and ephemeral nodes, powering many older distributed systems. etcd uses Raft, exposes a clean gRPC/HTTP API, supports leases and watch streams, and is the standard Kubernetes store. ZooKeeper wins on legacy ecosystem dependence; etcd wins on a modern API, simpler model, and cloud-native momentum.
| ZooKeeper | etcd | |
|---|---|---|
| Consensus | ZAB | Raft |
| API | Client libraries | gRPC / HTTP |
| Model | Znodes, watches | KV, leases, watch |
| Ecosystem | Legacy big-data | Cloud-native / K8s |
| Best for | Existing ZK systems | Modern KV/coordination |
Use case and API
ZooKeeper suits systems already built on it or needing its specific primitives. etcd suits new cloud-native coordination and config needs with a clean API, and it is the default in Kubernetes environments.
Ops and CI fit
etcd tends to be simpler to operate and reason about than ZooKeeper for new deployments. Both are integration-tested in CI against ephemeral quorums, where faster managed runners shorten cluster startup and watch/lease tests.
The verdict
Support an existing ZooKeeper-dependent system or need its primitives: ZooKeeper. Building modern cloud-native coordination or running Kubernetes: etcd. New work generally favors etcd; ZooKeeper endures under legacy platforms.