Vertical scaling (aka. scaling up)
Vertical scaling is a scalability technique that increases the capacity of a single server by giving it more CPUs, memory, storage, or network bandwidth. The system keeps running on one node; the node simply gets bigger. It is also known as scaling up, and it is the counterpart to horizontal scaling, which grows a system by adding nodes rather than enlarging them.
The aim is to raise throughput and lower latency on the existing deployment topology, without paying the coordination cost that comes with distributing work across multiple machines.
Where it fits
Vertical scaling is usually the first move when a workload outgrows its current node, because it changes nothing about how the system is deployed. There is no load balancing to introduce, no stateless redesign to undertake, and no partitioning of data. The application code keeps talking to the same single endpoint, only faster.
This makes vertical scaling especially attractive for stateful components that resist horizontal scaling. Relational databases and transactional databases have historically scaled vertically, by moving to a bigger server, because distributing consistent transactions across nodes is expensive (see the CAP theorem). When that single node finally reaches its ceiling, sharding and replication take over as the ways to grow further.
Trade-offs and limits
Vertical scaling has a hard ceiling. There is a largest machine you can buy or rent, and beyond that there is no more up to go. Hardware cost also rises superlinearly with size: a server with twice the cores and memory of a midrange box usually costs well more than twice as much, so the economics bend against vertical scaling at the high end.
A vertically scaled system is also a single point of failure that does not get any more available for being bigger. It is still one machine, and when it fails the whole service fails with it. To keep running through failures you need redundancy on top, which leads back toward horizontal techniques.
Most vertical moves require a restart. On bare metal, adding memory or CPUs means powering the machine down. On cloud platforms, changing a virtual machine’s instance type usually triggers a stop and start, so a vertical resize is a planned downtime event unless redundant nodes are already in place to absorb the traffic.
Elasticity
Vertical scaling is less friendly to automation than its horizontal counterpart. Auto-scaling controllers prefer to add and remove interchangeable instances, since that is a clean, reversible operation. Resizing a running node is more disruptive, so vertical auto-scaling is rarer and typically scheduled rather than reactive.