Concept · Requirements & scale
Vertical vs horizontal scaling
A bigger machine or more machines — and why the answer is usually "bigger, until it isn’t".
2 minscale upscale out
When a component runs out of capacity, you can make the machine bigger (scale up, vertical) or add more machines (scale out, horizontal).
| Vertical | Horizontal | |
|---|---|---|
| How | More CPU, RAM, faster disks | More instances behind a load balancer or partitioning |
| Code changes | None | The component must be stateless, or data must be partitioned |
| Limit | The largest machine you can buy or rent | Practically none |
| Failure | Still one machine | Losing one instance loses a fraction of capacity |
| Cost curve | Rises steeply at the top end | Roughly linear |
| Operational complexity | Low | Higher: coordination, rebalancing, more moving parts |
The usual answer
- Stateless tiers (web and API servers) should scale horizontally from early on. It's cheap once the servers are stateless, and it also gives you redundancy.
- Databases should scale vertically for as long as practical. A single large database is far simpler than a partitioned one, and modern machines with hundreds of gigabytes of RAM and fast NVMe storage take most applications a long way. Add read replicas for read load, and partition (range vs hash partitioning) only when writes or data size outgrow the biggest machine.
Don't forget redundancy
Even if one machine has enough capacity, run at least two of anything that must stay up, in different failure zones. Scaling decisions and availability decisions are separate: a vertically scaled database still needs a standby to fail over to.