<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Istio on Taubyte Blog</title><link>/blog/tags/istio/</link><description>Recent content in Istio on Taubyte Blog</description><image><title>Taubyte Blog</title><url>/blog/opengraph.jpg</url><link>/blog/opengraph.jpg</link></image><generator>Hugo -- 0.146.0</generator><language>en-us</language><lastBuildDate>Fri, 20 Feb 2026 16:00:00 +0000</lastBuildDate><atom:link href="/blog/tags/istio/index.xml" rel="self" type="application/rss+xml"/><item><title>Service Mesh: The Sidecar Tax That Eats Your Memory</title><link>/blog/posts/service-mesh-performance-fresser/</link><pubDate>Fri, 20 Feb 2026 16:00:00 +0000</pubDate><guid>/blog/posts/service-mesh-performance-fresser/</guid><description>&lt;p>Service meshes are everywhere. Istio. Linkerd. Consul Connect. Every microservices architecture needs one. Or so the marketing says.&lt;/p>
&lt;p>But here&amp;rsquo;s the thing: service meshes add sidecar proxies to every pod. Envoy, Istio&amp;rsquo;s sidecar, uses 50-200 MB RAM per pod. Linkerd-proxy uses 20-100 MB. Multiply by hundreds of pods. That&amp;rsquo;s gigabytes of memory just for service mesh overhead.&lt;/p>
&lt;p>All of this before your applications run. All of this just for inter-service communication. All of this overhead.&lt;/p></description></item></channel></rss>