etcd
Distributed, reliable key-value store for the most critical data of distributed systems. etcd uses the Raft consensus algorithm to maintain a strongly-consistent, highly-available store. Kubernetes uses etcd as its primary datastore. Agent systems use etcd for distributed coordination: leader election, service discovery, distributed locks, and configuration management.
Score Breakdown
⚙ Agent Friendliness
🔒 Security
mTLS strongly recommended — etcd stores Kubernetes secrets (if used as k8s backend). RBAC for fine-grained key prefix authorization. CNCF security audits completed.
⚡ Reliability
Best When
Your agent system needs strongly-consistent distributed coordination: leader election, distributed locks, or config watching.
Avoid When
You need high-throughput key-value storage — use Redis. You need large value storage — use S3/object storage. Application data belongs in a database.
Use Cases
- • Implement distributed leader election for agent coordinator processes that need a single active leader
- • Store and watch agent configuration changes that should propagate to all agent instances in real-time
- • Use etcd's distributed locks (leases) to prevent concurrent agent operations from conflicting
- • Implement agent service discovery by registering and watching agent service addresses in etcd
- • Store Kubernetes cluster configuration for agent operators that extend Kubernetes with custom resources
Not For
- • General application data storage — etcd is for coordination data (small, critical); use PostgreSQL for application data
- • High-write throughput — etcd is optimized for strong consistency, not write throughput; expect ~1000 writes/sec
- • Large values — etcd has a 1.5MB default value size limit; not suitable for large blobs
Interface
Authentication
etcd supports TLS client certificates (mTLS) and RBAC with user/role-based authorization. Token-based auth also available.
Pricing
Completely free and open source, CNCF graduated.
Agent Metadata
Known Gotchas
- ⚠ etcd is not a cache — data stored in etcd has strong consistency guarantees but limited throughput; don't use etcd as a general-purpose cache
- ⚠ Lease TTLs require keepalive — leases expire if the client doesn't send keepalive; agent crashes release leases after TTL, which is the desired behavior for leader election
- ⚠ Watch streams can be compacted — if an agent is disconnected and reconnects, the watch may return a 'compacted' error; agent must re-sync from current state
- ⚠ etcd cluster size must be odd for Raft quorum — 1, 3, or 5 nodes; 2 or 4 nodes provide no fault tolerance improvement over previous odd number
- ⚠ Large deployments require etcd defragmentation — etcd's backend grows with writes; schedule periodic defrag to reclaim space
- ⚠ Put operations are atomic but not batched by default — use Txn (transaction) for multi-key atomic operations in agent coordination workflows
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for etcd.
Scores are editorial opinions as of 2026-03-06.