etcd

etcd itself provides no data-at-rest encryption whatsoever: bbolt data files, WAL, and snapshot files are all written in plaintext. The 2019 Kubernetes SIG security audit explicitly states "not encrypted at rest"; encryption duty moves up to the kube-apiserver-layer EncryptionConfiguration (aescbc/aesgcm/KMS v2 plugins). Selection implication: if you use etcd as a general-purpose KV store and the data is sensitive, you must encrypt at the application layer yourself or rely on disk encryption; snapshots produced by etcdctl snapshot save are plaintext bbolt files — a leaked backup means leaked data.

Both client and peer communication can be configured with TLS, and mTLS is available (--client-cert-auth, using the client certificate CN as the username in authentication). v3.6.13/v3.6.14 fixed two consecutive issues: a CRL bypass (GHSA-3wh4-j44w-pg92) and a DoS where a TLS handshake without a deadline could exhaust goroutines (GHSA-6vch-q96h-7gc3). Mechanism in one line: Go standard TLS stack with limited certificate hot-reload support; production must configure mutual TLS completely, otherwise "having the certificate = having all the data".

The etcd server itself has no audit-logging functionality: who read or wrote which key at what time is not recorded by etcd. In Kubernetes scenarios, auditing relies on kube-apiserver's audit log. Selection implication: when compliance requires an audit trail of operations, etcd can only rely on a front proxy/gateway or host-level auditing — native capability is a blank.

Has RBAC: user/role model, permission granularity at key range read/write, authentication via password or TLS client-certificate CN; the root user is the superuser, requiring root to be created first and then etcdctl auth enable. Gaps: ① disabled by default, and not enabled in default Kubernetes deployments either (relying on network isolation + certificates); ② granularity only reaches key prefixes — no field-level, no row-level; ③ no native LDAP/OIDC integration; ④ authorization bypasses have had CVEs (nested Txn bypassing RBAC checks, CVE-2026-33343, fixed in v3.5.28; watch privilege escalation GHSA-xg4h-6gfc-h4m8, fixed in v3.6.14). Mechanism in one line: authorization does allow/deny decisions per key range at the v3rpc layer — simple but coarse.

Backup: etcdctl snapshot save takes a consistent snapshot online against a single member. Restore: starting with v3.6, etcdctl snapshot restore/status was removed and offline restore is now handled by etcdutl; restore is fundamentally downtime rebuild — bootstrap a new cluster from the snapshot (or join it as a new member); no online single-key/table-level restore, no PITR. Restore speed depends on snapshot size and how fast members replay WAL. Mechanism in one line: snapshot = bbolt-file-level-copy backup; restore = rebuild the cluster; there is no notion of logical or incremental backup.

/metrics exposes Prometheus metrics (--metrics=extensive enables the full set: Raft, WAL fsync, mvcc, watcher, etc.); etcdctl endpoint health/status checks member health and db size; etcdctl check perf runs write load tests; 3.6 added /livez /readyz (aligned with Kubernetes probe semantics) and Kubernetes-style feature gates; --enable-pprof; 3.6 introduced OpenTelemetry tracing. Key metrics: etcd_disk_wal_fsync_duration_seconds p99 (>10ms is dangerous), etcd_server_leader_changes_seen_total, dbSize/dbSizeInUse.

gRPC on port 2379 (HTTP/2 multiplexing), multiple streams over a single connection; clientv3 supports multi-endpoint configuration with round-robin load balancing and reconnect-on-failure; watch is a long-lived server-stream. Connection overhead is low — no application-level connection pool is needed or recommended (reuse one client instance). Note: watch count translates directly into server-side memory and fanout cost (see deep-dive II).

etcd's "transaction" = Txn: If (multi-condition comparisons) / Then / Else executed atomically, performing CAS (compare-and-swap) across multiple keys within a single Raft round-trip (comparison dimensions: value/version/createRevision/modRevision/lease). Isolation levels: all writes are linearizable (via leader + quorum + WAL fsync); reads come in two grades — linearizable (default, goes through quorum/ReadIndex) and serializable (leader local read; may return stale values but adds no latency). What it doesn't have: multi-statement interactive transactions, no rollback segments, no relational-style isolation-level matrix; client-side STM (e.g., the Go concurrency package, Node's microsoft/etcd3 software transactional memory) is optimistic concurrency assembled client-side on top of Txn — not equivalent to server-side transactions.

Raft (etcd-io/raft standalone library): all writes go through the leader, are fsynced to WAL, replicated to a majority before committing; CP system — during a partition the minority side cannot write and linearizable reads fail; no split-brain writes can occur. Read optimization: leader lease-based reads avoid going through quorum for every read. Membership changes go through Raft conf change, with learner support (no voting rights, promoted once it catches up on the log) for safely adding nodes.

Official recommendation is 3 or 5 members, at most 7 (diminishing returns and rising latency beyond that); no sharding, no horizontal write scaling — adding members does not increase write throughput, it increases quorum latency. Expanding = adding members (online, via learner); this is availability scaling, not capacity scaling. Capacity comes vertically: raise --quota-backend-bytes (default 2GB, recommended upper limit 8GB, startup warns above 8GB). Partially supported.

The v3 gRPC API is the stable interface; v2 API/v2store were removed in 3.6 (--enable-v2 deleted; residual non-member data refuses to start), and v2 code was fully deleted in 3.7. Client ecosystem: Go clientv3 (official), Java jetcd, Python (python-etcd3, etc.), Node microsoft/etcd3, Rust etcd-client. Migration note: during the 3.5→3.6 mixed-version period, the 3.5 feature set applies; Kubernetes apiserver has support-matrix requirements for etcd 3.5/3.6 (per the official Kubernetes matrix — exact version mapping to-be-verified).

Apache-2.0, CNCF-graduated project, no official commercial edition, no feature crippling. Business model = bundled with cloud vendors' managed Kubernetes + operations support from ecosystem companies. Selection implication: there is no such thing as "enterprise edition unlocks TDE/auditing" — capabilities that are missing are genuinely missing, not paywalled.

Official docs are primarily in English; there are community Chinese translation projects but they lag versions; Chinese blogs/books mostly focus on "etcd in Kubernetes operations" (backup, compact, tuning), with few Chinese-language deep materials on Raft/MVCC source-level internals. Below the Chinese ecosystem of MySQL/PG/Redis.

• Writes go through the Raft leader; single-cluster writes typically below tens of thousands of QPS; reads can scale via followers/learners 官方文档.
• Not a data-plane database: keep values at KB scale, don't use it as a general KV store 社区共识.
• Disk fsync latency directly determines write latency — the disk is the #1 performance component 社区共识.

• etcd is a CNCF graduated project with no official compliance certifications 社区共识.
• Compliance responsibility sits with the platform/product embedding etcd (e.g. managed Kubernetes offerings) 社区共识.

• Released 2013 by CoreOS; CNCF graduated 2020 社区共识.
• Kubernetes' default metadata store — enormous indirect install base 社区共识.
• Neutral governance with assured long-term maintenance; conservative feature evolution 社区共识.

• Every Kubernetes cluster uses etcd for metadata by default (public) 社区共识.
• Few public cases use etcd directly as a business KV store 社区共识.
• Cloud managed-Kubernetes offerings run it at scale behind the scenes 社区共识.

• Backup: etcdctl snapshot save/restore — simple and reliable 官方文档.
• No CDC/migration-tooling concept (simple KV semantics); monitoring via built-in Prometheus metrics 官方文档.
• The thin toolchain follows from its scope, not a weakness 社区共识.

• No official managed service 社区共识.
• Third parties (e.g. Aiven) offer managed etcd 社区共识.
• In practice mostly consumed indirectly via managed Kubernetes 社区共识.

• etcd stores config/metadata KVs, not a data platform; no bulk import tooling 官方文档.
• Recovery is via snapshot restore, not an ingest channel 官方文档.

• The KV API only reads/writes its own data; no federated queries or external tables 官方文档.

• The Watch API notifies on key prefix/range changes; usable as a lightweight subscription 官方文档.
• No durable change log, no exactly-once semantics — not CDC 社区共识.
• Past revisions are readable via revision, with limited retention 官方文档.

• Keys attach to leases; lease expiry auto-deletes the keys — native by design 官方文档.
• Leases need client keepalive; network partitions can cause premature deletion 社区共识.
• Built for metadata/config, not bulk business-data expiry 社区共识.

• Pure KV, no table structure, no DDL concept 官方文档.
• "Schema" lives only at the application layer: key-prefix namespacing and value-encoding conventions, evolved by application versioning — invisible to storage 社区共识.
• Data-format changes are managed by app versioning, unrelated to storage 社区共识.

• Built for cluster metadata/config; no multi-tenant resource isolation design 官方文档.
• The backend-bytes quota is global, not per-tenant 官方文档.

• Raft's strong consistency needs low latency; cross-region latency explodes 官方文档.
• Built as single-region cluster metadata storage 社区共识.

• Raft multi-replica; leader failure triggers re-election in seconds, RPO=0 官方文档.
• 3/5 nodes recommended; even counts are pointless 官方文档.
• Disk latency is the classic cause of election flapping 社区共识.

• etcd is a distributed KV store with no row/column concept; natively no RLS, column privileges, or masking 官方文档
• RBAC stops at key-prefix / range level and is the only isolation mechanism 官方文档
• Sensitive values can only be protected with client-side encryption 社区共识

• Values are opaque bytes; etcd does not parse JSON (N/A) 官方文档.
• Serialize/deserialize JSON client-side if needed 社区共识.

• No full-text concept (N/A) 官方文档.
• Key prefix/range queries are its retrieval model 官方文档.

• The underlying bbolt store is B+tree based with no data-compression mechanism; snapshot files are large. 官方文档
• Snapshot and WAL retention policies are configurable to bound disk usage, but that is operational control, not compression. 官方文档
• Metadata workloads are small, so missing compression matters little; etcd is not recommended for large data volumes. 社区共识

• etcd is open source under Apache 2.0 and a CNCF graduated project with mature community governance. 官方文档
• No license-change history; as Kubernetes' default metadata store, the ecosystem binds to an open standard, not a vendor. 社区共识
• Any compatible implementation can replace it; no commercial lock-in. 社区共识

• Pure KV reads/writes; no query-plan concept 官方文档.

• Lean parameters; the levers are backend quota and compaction intervals 官方文档.
• Large values and high-frequency watches are the classic tuning cases 社区共识.

• The underlying bbolt checks only meta pages; data pages have no page-level checksum, so corruption can be silent. (community tested)
• etcd ships experimental corruption detection and alerting (e.g. corrupt check) with limited coverage. 官方文档
• Production practice leans on quorum majority plus snapshot rebuilds of bad members, not page-level self-healing. 社区共识

• No stored-procedure/trigger concept (N/A) 官方文档.
• Transactions are multi-key atomic compare-and-swap, not procedural logic 官方文档.

• No FK/CHECK/unique concept (N/A) 官方文档.
• Consistency via Raft and leases, not data-integrity constraints 官方文档.

• No SQL, let alone analytical SQL (N/A) 官方文档.
• Operational insight via metrics, not queries 社区共识.

• etcd is MVCC storage: deletion only appends a tombstone revision, and old versions stay readable until compaction 官方文档
• Periodic compaction plus defrag is needed for physical reclamation; backend bbolt file history pages may retain data (community tested)
• Snapshot backups preserve historical states of deleted data 社区共识
• No erasure attestation 社区共识

• A distributed KV/config store; no data-lineage concept 官方文档.

• Raft consensus + bbolt local storage; classically coupled 官方文档.

• KV model only 官方文档.

• etcd is infrastructure for systems like Kubernetes with no built-in metering; cost folds into cluster hardware and operations labor. 社区共识
• Managed Kubernetes services typically bundle control-plane cost into the cluster fee. 厂商口径

• gRPC API with official Go/Java/Python clients 官方文档.
• No JDBC/ODBC (unneeded for KV) 社区共识.

• No materialized-view concept (N/A) 官方文档.
• Cache/config use cases need no pre-aggregation 社区共识.

• Open-source CNCF project; deploys anywhere 官方文档.
• Cross-cloud deployment is pointless (Raft is latency-sensitive); single-cloud/region is the norm 社区共识.

• The concurrency primitive is Raft-serialized writes plus MVCC: every write commits through the leader and applies in global revision order, with multiple versions kept per key. Concurrent writes to the same key have no "conflict" concept — only ordering — so there is no lock waiting, no abort, and no retry (retry ownership: not applicable, serialization eliminates conflicts). CAS semantics use a Txn If/Then comparing mod_revision; a failed condition returns the whole transaction and the application decides whether to retry. Decay comes from version accumulation, not conflicts. There is no built-in conflict detection (by design) 官方文档.
• Decay shape: every write, even to the same key, mints a new global revision plus a new bbolt entry and fsyncs through a Raft quorum. A hot key's high-frequency updates inflate that key's version chain and bbolt indefinitely, raising historical-revision read and compaction costs. Exhausting the backend quota (default 2GB via --quota-backend-bytes, 8GB max recommended) raises a NOSPACE alarm and turns the whole cluster read-only — and it stays read-only after deletions until an operator manually compacts, defragments, and clears the alarm. The single-point bottleneck is the leader's disk fsync capacity (on the order of ten thousand writes/sec); adding members does not add write throughput 官方文档.
• Built-in mitigation (limited): no evidence found for an officially named or documented hotspot detection, rate-limiting, spreading, or queueing mechanism (not verified absent). Auto-compaction (--auto-compaction-mode=revision/periodic, present since 3.x) periodically discards old versions — hygiene, not hotspot spreading; skipping compaction ends in quota exhaustion and read-only mode. The application pattern: hot data like high-frequency counters or event streams does not belong in etcd by design (it is a low-frequency coordination store); if it must, use short-lived lease keys and keep each value under 1.5MB (--max-request-bytes, oversized requests are rejected outright), at the cost of moving business state to a queue or time-series store (to be verified).
• Boundaries: clients watching a hot key are woken on every update, amplifying hotspot writes into a notification storm, and slow consumers drag the whole system down — backpressure is the application's job (the core has no backpressure queueing). A slow disk causes leader heartbeat timeouts and repeated elections, collapsing write latency from milliseconds to seconds — coordination cost grows superlinearly with contention. Retry ownership: watch disconnects reconnect client-side, write failures retry application-side. The application pattern: aggregate and throttle on the watcher side of hot keys (cost: reduced notification freshness). Production guidance: keep high-frequency updates to a single key within roughly 1,000 QPS (to be verified: the stability guideline is documented for overall write rates; no exact source for a single-key figure) — beyond that, revision bloat and compaction costs spike sharply 社区共识.