We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningFoundation · Core Fundamentals
Making a single machine more powerful (more CPU, RAM, storage). Simpler but has physical limits. Also called 'scaling up.'
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Vertical Scaling across a run of lessons, not one page. These 4 alone are about 98 minutes of step-by-step reading, every one with a quiz.
Adding resources to a single node to handle more load.
How systems grow to handle more users, more data, and more traffic without falling apart.
How a GSLB decides which region a user reaches, and why the decision takes minutes to arrive even when it is made in microseconds.
Adding more nodes to a system to distribute load.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Vertical Scalingpay once,
yours for life
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.
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 vCPUs on general purpose types, while specialized memory-optimized types reach hundreds of vCPUs and 24 TB or more of RAM, 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.
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.
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.
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.
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.
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.
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.
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.
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.
Scalability
How systems grow to handle more users, more data, and more traffic without falling apart
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
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.
This page explains the idea. The "Vertical Scaling" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Vertical Scaling lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Vertical Scaling in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
