# Vertical vs horizontal scaling

> A bigger machine or more machines — and why the answer is usually "bigger, until it isn’t".

Concept · Requirements & scale · https://levelcode.org/concepts/vertical-vs-horizontal-scaling

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](https://levelcode.org/concepts/stateless-services), 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](https://levelcode.org/concepts/sharding)) 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.