etcd

Etcd is the distributed key-value store that handles that consensus. Kubernetes uses it as its brain. Every piece of cluster state lives in etcd. When people say their Kubernetes cluster is down, half the time etcd is the problem.

Everything is free under Apache 2.0. CNCF graduated project. No paid tier, no enterprise edition. Maintained by contributors from Red Hat, Google, and the broader Kubernetes ecosystem.

Self-hosting is the only option, and it requires understanding distributed systems. A production etcd cluster needs 3 or 5 nodes (odd numbers for quorum), fast SSDs (etcd is write-heavy), and careful monitoring. It's not a general-purpose database. It's designed for small, critical metadata. Solo developers: you don't need etcd directly. If you're running Kubernetes, it's already there. Small teams: same. Let your Kubernetes distribution manage etcd for you. Platform engineers: you need to understand etcd's health, compaction, and backup procedures because when etcd is unhappy, everything is unhappy.

The catch: etcd is not a general-purpose database. It's optimized for small key-value pairs (metadata, configuration, leader election) with strong consistency. Don't store application data in it. The recommended data size limit is 8GB. If you need a distributed KV store for application data, look at Redis or DragonflyDB.