Vertical vs. Horizontal Scaling

There are exactly two ways to give a system more capacity, and they have very different ceilings and failure characteristics.

Vertical scaling (scale up)

Buy a bigger machine — more CPU, more RAM, faster disks.

Pros: no architectural change, no distributed-systems complexity,
      strong consistency is trivial (it's one machine)
Cons: hard ceiling (there's a biggest machine money can buy),
      single point of failure, expensive at the high end,
      usually requires downtime to resize

Horizontal scaling (scale out)

Add more machines and distribute the load across them.

Pros: near-unbounded ceiling, no single point of failure,
      commodity hardware is cheap per unit
Cons: real complexity — now you need load balancing, data
      partitioning, and to reason about consistency across nodes

The actual decision rule

Default to vertical scaling until it demonstrably can't keep up, then scale horizontally. This isn't a compromise — it's the right call, because horizontal scaling's costs (operational complexity, consistency headaches, network partitions) are real and ongoing, while vertical scaling's ceiling is much higher than most systems ever reach. The common mistake is reaching for a horizontally-scaled, sharded, multi-region architecture for a system that would run comfortably on one large database server for years.

Almost every famous "we scaled to millions of users" story still involved running on a single primary database for longer than people expect. Horizontal scaling is a tool for a demonstrated bottleneck, not a default starting posture.