Vertical Scaling
Making a single machine more powerful (more CPU, RAM, storage). Simpler but has physical limits. Also called 'scaling up.'
What is Vertical Scaling?
In short
Vertical scaling, also called scaling up, means adding more power to a single machine: more CPU cores, more RAM, faster or larger disks. You handle more load by upgrading one server instead of adding more servers.
What Vertical Scaling Actually Is
Vertical scaling is the act of making one machine stronger so it can do more work. Instead of running your database on a box with 4 CPU cores and 16 GB of RAM, you move it to a box with 32 cores and 256 GB of RAM. The application does not change. The architecture does not change. You just gave the same process a bigger machine to run on.
This is the opposite of horizontal scaling, where you add more machines and spread the load across them. With vertical scaling there is still exactly one server doing the job, it is simply a faster one.
On cloud providers this is usually a single setting. On AWS you change an EC2 instance from t3.large to m6i.4xlarge. On a managed database like Amazon RDS or Google Cloud SQL you pick a bigger instance class and apply it. The same data and the same code now run on more hardware.
How It Works Under the Hood
When you scale up in the cloud, the provider does not physically swap chips into your running box. It stops your instance, places it on a host with more capacity, and starts it again, which is why a resize almost always needs a reboot. That reboot is the main cost: a few seconds to a few minutes of downtime unless you have a standby replica to fail over to.
More RAM is often the biggest win because it lets a database keep more of its working set and indexes in memory instead of reading from disk. A Postgres or MySQL instance that was hitting disk on every query can become an order of magnitude faster simply by having enough memory to cache the hot data. More CPU cores help with concurrent connections and parallel query execution, and faster NVMe storage cuts the cost of the reads that still touch disk.
The ceiling is physical. A single machine can only hold so many cores and so much memory. As of 2026 the largest cloud instances top out around 192 to 224 vCPUs and 24 TB of RAM on specialized memory-optimized types, but most workloads hit a price wall long before the hardware wall, because the top instance sizes cost far more per unit of compute than mid-range ones.
When To Use It And The Trade-offs
Vertical scaling is the right first move when your system is hard to split across machines. Relational databases are the classic example: keeping all the data on one primary avoids the complexity of sharding, distributed joins, and cross-node transactions. Many companies run a single large Postgres or MySQL primary into the millions of users before they ever shard, precisely because scaling up is so much simpler.
The upside is simplicity. There is no load balancer to configure, no data partitioning, no consistency problems between nodes, and the code stays exactly the same. For a small team this saves enormous engineering time.
The downsides are real. You have a hard ceiling once you reach the biggest machine available. Cost grows faster than capacity at the high end. And a single big server is a single point of failure: if it goes down, everything goes down, so you still need a replica for availability even though that replica does not add scaling capacity. Most mature systems use vertical scaling as the easy lever first, then move to horizontal scaling once one machine is no longer enough or no longer cost-effective.
A Concrete Example
Stack Overflow famously ran its entire main site for years on a small number of beefy servers rather than a sprawling cluster. Their SQL Server database lived on a single primary with hundreds of gigabytes of RAM and fast SSDs, serving billions of page views, because keeping the data on one powerful machine was simpler and faster than distributing it.
A typical growth path looks like this. You launch on a 2 vCPU, 8 GB database instance. Traffic grows and queries slow down, so you resize to 8 vCPU and 64 GB during a low-traffic window, accepting a one to two minute reboot. That buys you another year. Eventually you reach the largest practical instance and the cost becomes painful, which is the signal that it is time to add read replicas or shard the data horizontally.
The lesson most engineering teams learn is to scale up until it stops being easy or cheap, then scale out. Vertical scaling is rarely the final answer at massive scale, but it is almost always the correct cheapest answer at the start.
Where it is used in production
Stack Overflow
Ran its main site for years on a handful of very large servers with a single SQL Server primary holding hundreds of GB of RAM rather than a large distributed cluster.
Amazon RDS
Lets you scale a managed database up by selecting a larger instance class, applying it with a brief reboot, going up to memory-optimized sizes with terabytes of RAM.
PostgreSQL
Commonly scaled vertically to a single large primary with enough RAM to cache the working set, deferring sharding until one machine is no longer enough.
Amazon EC2
Provides a direct scale-up path by resizing an instance type, for example from t3.large to m6i.4xlarge, to add CPU, memory, and network capacity.
Frequently asked questions
- What is the difference between vertical and horizontal scaling?
- Vertical scaling adds more power to one machine, such as more CPU, RAM, or faster disk. Horizontal scaling adds more machines and spreads the load across them. Vertical is simpler but has a hard physical ceiling, while horizontal scales further but adds complexity like load balancing and data partitioning.
- Does vertical scaling require downtime?
- Usually a short one. On most cloud providers a resize stops the instance, moves it to a bigger host, and reboots it, which takes seconds to a few minutes. You can avoid user-facing downtime by failing over to a standby replica during the resize.
- What are the limits of vertical scaling?
- A single machine can only hold so many cores and so much memory. As of 2026 the largest cloud instances reach roughly 192 to 224 vCPUs and up to 24 TB of RAM, but cost per unit of compute rises sharply at the top sizes, so most teams hit a price ceiling before the hardware ceiling.
- When should I scale up instead of scaling out?
- Scale up first when the workload is hard to distribute, like a relational database that you do not want to shard yet. It keeps the architecture simple and the code unchanged. Switch to scaling out when one machine is no longer big enough or the largest instance is no longer cost-effective.
- Is vertical scaling cheaper than horizontal scaling?
- At small to medium scale it is usually cheaper because you avoid the engineering cost of distribution and run fewer moving parts. At large scale it gets expensive because top-tier instances cost far more per unit of capacity, which is when horizontal scaling becomes more economical.
Learn Vertical Scaling hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Vertical Scaling as part of a larger topic.
Scalability
How systems grow to handle more users, more data, and more traffic without falling apart
foundation · core fundamentals
Scaling and GPU Infrastructure: Serving Models Without Burning Money
Why GPU serving gets expensive and how to fix it: the VRAM ceiling, batching, quantization, distillation, caching, card sharing, bin-packing, parallelism, autoscaling, spot, and horizontal vs vertical scaling
ml-foundation · core
See also
Related glossary terms you might want to look up next.
Horizontal Scaling
Adding more machines to handle increased load (scaling out). Like opening more checkout lanes instead of making one cashier faster.
Load Balancer
Distributes incoming traffic across multiple servers so no single server gets overwhelmed. Like a traffic cop directing cars to different lanes.
Latency
The time delay between sending a request and getting a response. Amazon found every 100ms of extra latency costs 1% in sales.
Throughput
The number of operations a system can handle per unit of time. Think of it as how many cars a highway can move per hour.
Bandwidth
The maximum amount of data that can be transferred over a network in a given time. It's the width of the pipe, not how fast the water flows.
TCP
A reliable transport protocol that guarantees data arrives in order and without errors. It uses a three-way handshake to establish connections.