A single process is easy; quorum is the product
etcd starts a local server on ports 2379 and 2380, then etcdctl put and get are enough to prove the basic path. That small demo can give the wrong impression. The useful part is a replicated log whose members agree on one order of changes. Clients get watches, leases, transactions, and a gRPC API for control data that cannot tolerate two conflicting answers.
That makes etcd a good fit for configuration, coordination, and leader election. It is a poor substitute for a general application database. Exact history consumes space, write progress depends on quorum, and every member participates in a failure model the operator must understand. The README's three-member local example is closer to the production idea than the one-command single server, even though three processes on one laptop do not test machine failure.
What happened when we ran it
Our sandbox installed commit 64f26db in 102 seconds and added 559 packages. The build completed in 57 seconds. The Go test step finished in 16 seconds with 4 passed and 0 failed. We used a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Go 1.24, and no secrets.
The checkout contained 1,493 files, about 225,522 lines of source, and occupied 15.2 MB. We also found 11 CI workflow files, a Dockerfile, and a tests directory. Those are useful repository signals, while the passing 4-test step only describes the command our harness selected. It does not stand in for the project's larger test systems or its separate reliability testing.
Our run did not measure request latency, write throughput, failover time, or behavior during a network partition. It also did not create a multi-machine cluster. The defensible result is narrower: commit 64f26db installed, built, and passed the available test step in our container. Capacity and failure claims still need a workload and topology that resemble your deployment.
Three members survive one permanent loss
A 3-member cluster can tolerate 1 permanent member failure because etcd needs a majority to make progress. Lose 2 permanently and quorum is gone. The v3.7 recovery guide says updates stop at that point, and restoration from a snapshot creates a new logical cluster with new member and cluster identities. That is a reason to rehearse recovery, not merely schedule a backup command.
Kubernetes adds another wrinkle. Restoring an older snapshot can move the revision backward while controllers retain watch-based caches. The official guide recommends a revision bump and marking the restored revision compacted so watchers terminate and rebuild their view. An operator who has never tested that sequence is trusting the most important recovery procedure to syntax read during an outage.
TLS and authentication are disabled by default
The v3.7 security guide states that transport security and RBAC authentication are not enabled by default. A production cluster therefore needs an explicit policy for client traffic on 2379 and peer traffic on 2380. The documented route uses a CA and signed key pair for each member, with separate flags for server certificates, trusted CAs, and peer certificate checks.
This is reasonable machinery for infrastructure that stores credentials, desired state, or cluster membership, but it is still machinery. Certificate names must match how peers connect, renewals cannot strand a member, and clients need the right trust chain. Starting the binary without those controls proves that etcd runs. It does not prove that the endpoint is safe to expose.
Compaction and defragmentation are recurring work
The v3.7 maintenance guide says a live-member defragmentation blocks reads and writes on that member while it rebuilds state. Compaction first removes old key revisions from the usable history; defragmentation then returns the resulting free space to the filesystem. Operators must apply defragmentation per member and watch the space quota, because a full backend raises a cluster-wide alarm that limits normal writes.
Disk quality also affects availability. The hardware guide calls disk write latency the most important performance and stability factor, since a majority must persist requests and slow writes can delay heartbeats enough to trigger elections. Its typical starting point is 2 to 4 CPU cores, 8 GB of memory, and at least 50 sequential IOPS, with dedicated resources and workload testing advised for production.
October activity is strong, but v3.7.2 needs testing
GitHub showed 52,323 stars, 130 open issues, and 243 open pull requests on October 5, 2026. The repository was pushed on October 4. Release v3.7.2 shipped on September 22 alongside v3.6.15 and v3.5.34, evidence that maintainers are servicing three release lines rather than only moving main forward. The README also lists weekly community and issue-triage meetings.
Active maintenance does not make every upgrade automatic. Open issue #22500 reports that the v3.7 MsgApp stream writer can spend 3 to 5 times more CPU per message than v3.6 in the reporter's encoder test, with v3.7.2 among the affected versions. That is the reporter's measurement, not ours, but the issue is specific enough to justify a representative upgrade test before moving a busy cluster to v3.7.2.
etcd belongs under control planes, not ordinary records
etcd v3.7.2 makes sense when a system needs a small, strongly consistent source of truth and the team can operate its failure model. Consul is the better comparison when service discovery and network policy lead the requirements. ZooKeeper fits dependencies already built around its coordination model. TiKV is aimed at a much larger transactional data role.
Our 57-second build and 4 passing tests make the source approachable for a project of 225,522 lines. They do not make a safe cluster effortless. Pick etcd for the semantics, then budget for three members, low-latency disks, two secured network paths, compaction, snapshots, and a restore drill. If those duties sound excessive for the data being stored, that is the answer: use something smaller.