Vertical Scaling

Vertical scaling, often called “scaling up”, means making a single machine more powerful. You add more CPU, more RAM, faster disks, or a better network card. The application stays the same; the hardware under it gets bigger.

The idea

Before:                After scaling up:
+-----------+          +-------------------+
| 2 CPU     |          | 16 CPU            |
| 8 GB RAM  |   --->   | 128 GB RAM        |
| 1 server  |          | 1 bigger server   |
+-----------+          +-------------------+

There is still one server. It just handles more work because it has more resources.

Why teams love it at first

It is the easiest kind of scaling. You do not change your code or your architecture. You resize the machine and keep going.

# Conceptually, on a cloud provider:
# change instance type from "small" to "xlarge"
resize-server --from small --to xlarge

A monolith that runs on one box can often be scaled up with zero code changes.

Advantages

• Simple: no code or architecture changes.
• No need to handle distributed state or coordination.
• Lower software complexity; everything stays in one place.
• Great for databases, which are hard to split.

Disadvantages

• There is a hard ceiling: the biggest machine you can buy.
• Cost grows faster than power at the high end.
• A single machine is a single point of failure.
• You usually need downtime or a restart to resize.

Vertical vs horizontal

Vertical   : one machine, made bigger      (scale up)
Horizontal : many machines, added together  (scale out)

When to use it

Scale up first when load is moderate, when the system is a monolith, or when the bottleneck is a database that is hard to distribute. It buys you time with little effort.

When it stops working

Once you hit the largest available machine, or you need high availability that one server cannot give, you must scale horizontally by adding more machines. Many real systems use both: bigger machines and more of them.