Back to blog

Stop Stacking CDNs: Why One is Enough
At Pinata, we’ve seen our fair share of setups when it comes to delivering content on IPFS. People use our Dedicated IPFS Gateways to serve their files quickly and reliably across the globe. But every now and then, we see users trying to stack another CDN on top of their gateway, thinking it’ll improve performance. Spoiler alert: it won’t. In fact, it’ll probably make things worse. That’s because every Dedicated Gateway comes with a built-in CDN.
The Cache Coherence Problem
When you add a second CDN on top of another, you introduce a cache coherence problem—basically, your files aren’t always in sync. One CDN might cache a file longer than the other. Or worse, one CDN might purge a file while the other keeps serving an older version. This leads to stale content issues, meaning your users might see outdated files even after you’ve made updates. Not great.
This problem is compounded when people not only stack CDNs but also storage providers. Storing files on another more traditional storage layer in addition to IPFS is a form of caching. However, even with CDNs, this causes content updates to be significantly slower while increasing infrastructure costs.
Slower, Not Faster
You’d think two CDNs mean twice the speed, right? Wrong. Every additional CDN adds more hops to the request path. Instead of your file being served directly from the closest edge node, it now has to go through another layer of caching and validation. This actually increases latency instead of reducing it. You might even see delays in file availability since one CDN has to wait for the other to fetch fresh content.
Purging Becomes a Nightmare
CDNs work great when they’re the single source of truth for cache invalidation. The second you introduce another CDN, purging becomes unreliable. If you clear a file from one but not the other, users might get different versions of your content depending on which CDN they hit. This is especially problematic for things like NFT metadata, where consistency matters.
Hidden Costs, More Headaches
Stacking CDNs means you’re paying for redundant services. You’re already getting the benefits of caching, redundancy, and global distribution from one CDN—why pay twice for the same thing? Not to mention, debugging performance issues across multiple CDNs is a massive headache. You don’t want to spend hours trying to figure out which layer is serving stale content.
Pinata Dedicated IPFS Gateways Have a Built-In CDN
All Pinata Dedicated IPFS Gateways come with a built-in CDN, ensuring your content is delivered quickly and reliably across the globe. Our CDN is optimized for IPFS performance, high availability, and global distribution, so you don’t need an additional layer on top. We’ve designed it to handle everything you need for delivering fast, reliable content without the need for extra configurations.
How Does CDN Stacking Happen In The First Place
Most of the time, we’ve seen customers add CDNs on top of their existing Pinata Gateway and CDN because they didn’t realize their Gateway acted as a CDN as well. That’s something we’re always trying to get better about communicating.
However, in some cases, we see customers stack CDNs because they think it will be cheaper. As mentioned earlier, this often backfires and ends up costing customers more while increasing complexity.
The Bottom Line
More CDNs ≠ More Speed. More CDNs = More Problems.
If you’re using a Pinata Dedicated IPFS Gateway, you don’t need to stack another CDN on top. It won’t make your files faster, but it will introduce cache inconsistencies, purging headaches, and unnecessary costs. Keep it simple. Stick with one.
Happy Pinning (and caching)!