Your application is getting more traffic. Congratulations, you have a good problem. Now you need to scale.
At this point, every blog post, conference talk, and senior engineer in your life will present you with two options. Two respectable, battle-tested approaches. The approved choices.
The two options you’re allowed to pick
Vertical scaling is the straightforward one. Your server can’t handle the load? Get a bigger server. More CPU, more memory, more everything. It works, and it’s satisfying in the same way that buying a larger hard drive is satisfying. The problem is that physics eventually gets in the way. Good luck finding a machine with 400+ CPUs. They exist, but you’ll pay for the privilege.
Horizontal scaling sounds more sophisticated. Instead of one big server, you run many smaller ones. A load balancer distributes traffic between them. Infinite scalability, right? Well, yes, but there’s a catch. Your application needs to support this. If you’re storing session data in memory, horizontal scaling will turn your users’ experience into a lottery. They’ll get different data depending on which server they land on. So you need to externalize state, add a shared cache, and accept the architectural complexity that comes with it. And then there’s the database. You can add application servers all day, but they all talk to the same database. At some point, that database becomes the bottleneck, and horizontally scaling databases is a whole different beast. Sharding, replication, consistency trade-offs. It gets complicated fast.
Both approaches have their place. Both require trade-offs. And both are exhaustively documented.
But there’s a third option that rarely comes up.
The scaling approach nobody mentions
I call it “natural scaling” for lack of a better term. The idea is simple: what if you kept each application instance small enough that it never needed to scale?
Instead of one application serving all your users, you run many small applications, each serving a subset. Each instance handles so little traffic that scaling becomes irrelevant.
Consider GitHub, hypothetically. Imagine if each organization got its own dedicated server. Your organization’s server handles traffic for your repositories, and that’s it. The load is inherently limited because the user base is inherently limited. You don’t need to scale that server. You need more servers, but each individual server stays small and manageable.
This isn’t hypothetical at Upsun. Every project on our platform gets its own dedicated API server. We don’t have one API server that needs to scale to handle all projects. We have thousands of small API servers, each handling exactly one project.
The catch (because there’s always a catch)
Natural scaling trades one problem for another. You don’t have to worry about scaling anymore. Instead, you have to worry about operating a fleet.
Deploying three servers is fine. You can do it manually if you have to (though you shouldn’t). Deploying 10,000 servers is a different discipline entirely. Your automation has to be flawless. Your deployment pipeline has to be bulletproof. Every update, every security patch, every configuration change has to roll out consistently across the entire fleet.
This may be why natural scaling doesn’t get discussed much? The operational overhead is significant. You’re trading application complexity for infrastructure complexity. For many teams, that’s not a trade they want to make.
So why consider it?
Because sometimes the trade-off makes sense. If your product naturally segments into isolated units (tenants, organizations, projects), natural scaling aligns with your architecture. You get isolation for free. One customer’s traffic spike doesn’t affect another customer. One customer’s data stays completely separate from another’s.
And you never have to have the “we need to rewrite for horizontal scaling” conversation.
Is this the right approach for every application? No. Is it discussed as often as it should be? Probably not. Worth considering the next time someone tells you that you have exactly two options for handling scale. Last modified on April 14, 2026
