etcd
GraduatedOrchestrationetcd is a distributed, strongly consistent key-value store built on the Raft consensus algorithm. It's the backing store for Kubernetes cluster state — every object, every config, every secret in a K8s cluster lives in etcd.
What it is
etcd is a distributed, strongly consistent key-value store built on the Raft consensus algorithm. It's the backing store for Kubernetes cluster state — every object, every config, every secret in a K8s cluster lives in etcd. Outside Kubernetes, it's used anywhere you need a small, reliable, linearizable store for coordination data: leader election, service discovery, distributed locks, config that needs to be consistent across nodes.
It is not a general-purpose database. Don't put application data or anything bulky in it. It's optimized for small values, high read/write consistency, and low-latency watch notifications — not throughput or storage volume.
Who builds it and why
etcd started at CoreOS, was adopted as the default state store for Kubernetes early on, and moved under CNCF governance where it reached Graduated status. Google, Red Hat, and the broader Kubernetes SIG community (particularly SIG API Machinery and SIG etcd) now drive most of the maintenance, because etcd's health is directly tied to Kubernetes' health — if etcd falls over, the cluster control plane falls over. 1,179 contributors and continued active commits (latest as of mid-2026) reflect that it's maintained as critical infrastructure, not a side project.
Production readiness signal
This is about as production-proven as distributed systems software gets. It's been the single point of truth for essentially every Kubernetes cluster on the planet for close to a decade. 51,923 GitHub stars and Graduated CNCF status confirm ecosystem maturity, but the real signal is operational: etcd's failure modes, quorum behavior, and performance characteristics under load are extremely well documented because so many people have hit them in production.
That said, "production ready" doesn't mean "operationally simple." etcd is sensitive to disk I/O latency, network jitter between members, and cluster size. Running it well — especially at scale, self-hosted, outside a managed Kubernetes offering — requires real operational discipline: fast local SSDs, careful backup/restore procedures, and monitoring for things like DB size growth and leader election churn.
Who should use this
- Anyone running self-managed Kubernetes control planes — you don't get a choice here, etcd is the default.
- Teams building distributed systems that need strongly consistent coordination primitives (leader election, distributed locks, service registry) and are comfortable operating a Raft-based store.
- Platform teams who need a lightweight, well-understood store for config/state that must be consistent across a small number of nodes.
Who should NOT use this
- Anyone looking for a general-purpose database. etcd has hard practical limits (default 2GB-8GB recommended DB size) and isn't built for large datasets or high-throughput application data.
- Teams wanting a managed experience without operational overhead — if you're on EKS, GKE, or AKS, the cloud provider manages etcd for you; don't stand up your own unless you have a specific reason to self-host Kubernetes.
- Use cases needing eventual consistency at massive scale (think: caching layers, session stores at high QPS) — look elsewhere, etcd's consistency guarantees come at a throughput cost.
- Teams without dedicated ops capacity for distributed systems. Misconfigured etcd clusters (bad disk, undersized nodes, wrong quorum) are a top cause of Kubernetes control plane outages.
Alternatives
- Consul (HashiCorp) — similar Raft-based coordination store, with built-in service discovery and mesh features etcd doesn't have.
- ZooKeeper — older, JVM-based coordination service, still common outside the Kubernetes/cloud-native world (Kafka, Hadoop ecosystem).
- CockroachDB / TiKV — if you actually need a distributed SQL/KV store with more scale and query capability, not just coordination primitives.
Pricing
Fully open source, Apache-2.0 licensed. No paid tier, no vendor lock-in on the project itself. Cost is entirely operational — infrastructure and the engineering time to run it reliably, or the cost of a managed Kubernetes offering that abstracts it away for you.