/blog/tags/etcd/Recent content in Etcd on Taubyte Blog/blog/opengraph.jpg/blog/opengraph.jpgHugo -- 0.146.0en-usThu, 19 Feb 2026 16:00:00 +0000/blog/posts/etcd-performance-fresser/Thu, 19 Feb 2026 16:00:00 +0000/blog/posts/etcd-performance-fresser/<p>etcd sits at the heart of Kubernetes. Before your applications run, etcd is storing cluster state, coordinating elections, and replicating data. It consumes 2-8 GB RAM per node. It requires 3-5 nodes for high availability. That&rsquo;s 6-40 GB RAM just for cluster coordination.</p> <p>Most teams don&rsquo;t need distributed consensus. Most teams don&rsquo;t need high availability at the cluster level. Most teams are running small clusters that would work fine with a single node and backups.</p>/blog/posts/why-raft-fails-in-production-and-how-taubyte-raft-fixes-it/Thu, 29 Jan 2026 12:00:00 +0000/blog/posts/why-raft-fails-in-production-and-how-taubyte-raft-fixes-it/Most Raft implementations look great in theory and fall apart in practice. The algorithm itself isn&rsquo;t the problem—it&rsquo;s everything around the algorithm that breaks in production: bootstrapping, discovery, leader routing, rejoin behavior, and what happens when nodes start out of order or the network is unreliable. Taubyte&rsquo;s Raft wraps HashiCorp Raft and adapts it with libp2p transport, Taubyte discovery, and datastore-backed persistence. The goal isn&rsquo;t to reinvent consensus—it&rsquo;s to make consensus operable. Nodes can start in any order and converge to a working cluster without static seed lists or fragile bootstrap rituals. This article explores how Taubyte&rsquo;s Raft addresses the operational challenges that make Kubernetes/etcd fragile and compares it to typical Raft libraries.