Horizontal vs Vertical Scaling

A bigger machine or more machines — and the real trade-off behind that choice

Verticalbigger machine, hard ceiling
Horizontalmore machines, no hard ceiling
Cost curvenon-linear vs roughly linear
Ops complexitysimple vs load balancing + coordination

1.Horizontal vs vertical scaling

Vertical scaling means moving to a bigger machine — more CPU, more RAM, on the same single instance. Horizontal scaling means adding more machines and spreading the work across them. They solve the same problem — not enough capacity — in structurally different ways.

Key features

Vertical scaling: upgrade one instance to more CPU/RAM/disk — same architecture, bigger box
Horizontal scaling: add more instances and distribute load across them
Vertical scaling has a hard ceiling — the largest machine a cloud provider or vendor sells
Horizontal scaling has no such ceiling, in principle, but requires the workload to be distributable
Vertical scaling usually needs no code change; horizontal scaling requires load balancing and, often, statelessness

Vertical vs horizontal scaling

Vertical vs horizontal scaling
Property	Vertical (scale up)	Horizontal (scale out)
Mechanism	Bigger single machine	More machines
Ceiling	Largest machine available	No hard ceiling, in principle
Code changes needed	Usually none	Load balancing, often statelessness
Downtime to scale	Often requires a restart/resize	New instances join without downtime
Cost curve	Non-linear — big machines cost disproportionately more	Roughly linear per added instance

Vertical vs. horizontal scaling

Vertical (scale up)

One instance, bigger CPU/RAM/disk
Hard ceiling — the largest machine available
Usually no code change needed

Horizontal (scale out)

More instances, load balanced
No hard ceiling, in principle
Needs a distributable workload, often statelessness

Command

text

vertical:   1 instance, size ↑  (CPU, RAM, disk)
horizontal: N instances, N ↑    (load-balanced)

Vertical scaling means a bigger machine and has a hard ceiling; horizontal scaling means more machines and has (in principle) none, at the cost of needing a distributable workload.

2.Scaling trade-offs: limits, cost curves and operational complexity

Choosing vertical vs horizontal scaling is not just "which one is possible" — it is a trade-off between cost curve (does price rise linearly or steeply), operational complexity (does it need load balancing, replication, coordination), and how close the workload is to its scaling limit either way.

Key features

Vertical scaling cost is often non-linear — doubling a machine's specs frequently costs more than double
Horizontal scaling cost is closer to linear — each added instance costs about the same as the last
Vertical scaling adds little operational complexity — same architecture, no new coordination
Horizontal scaling adds real complexity — load balancing, and for stateful systems, replication or sharding
The right choice depends on where the workload already sits relative to each approach's limit

Three axes the scaling decision actually turns on

Cost curve

linear vs non-linear pricing

Blast radius

one instance dying vs 25%

Ops complexity

none vs load balancing/replication

Command

text

vertical:   simpler ops, non-linear cost, hard ceiling
horizontal: more ops complexity, ~linear cost, no hard ceiling

Vertical scaling is operationally simpler with a non-linear cost curve and a hard ceiling; horizontal scaling is closer to linear cost with no hard ceiling, at the price of real operational complexity — choose based on where the workload sits relative to each limit, not by default.

3.Check statelessness before committing to horizontal scaling

Before choosing horizontal scaling for a component, check whether it can actually be made stateless — because a stateful component does not automatically get easier to scale out just because more machines were added; it needs its state relocated first, or scaling out will not help.

Key features

Horizontal scaling assumes any instance can take any unit of new work
A component with local, unshared state breaks that assumption until the state is moved out
Checking statelessness is a design-time question, not an operational afterthought once traffic already grew
Some components are inherently harder to make stateless (a database itself) — those need replication/sharding, not just "add instances"
A component confirmed stateless can usually be scaled horizontally with only a load-balancer change, no further redesign

Check statelessness before scaling out

yesno

Can any instance handle any request?

Add instances

done

Relocate state first

e.g. move cache to Redis

Command

text

before choosing horizontal scaling, ask:
  can any instance handle any request right now?
  yes → add instances, done
  no  → relocate the state first, THEN add instances

Check whether a component is actually stateless before choosing horizontal scaling as the fix — a stateful component needs its state relocated first, or the new instances will not deliver the expected capacity.

Spotted a mistake on this page? Tell us.

Read Sheet