Vertical scaling means making a single machine more powerful: more CPU cores, more memory, faster disks. It’s usually called scaling up, as opposed to horizontal scaling, which adds more machines.
On a cloud provider this is often a dropdown and a restart. You change the instance type, the machine reboots on bigger hardware, and nothing about your application has to change. That is the entire argument for it, and it’s a strong one.
Why to reach for it first
- No architectural work. Scaling out requires stateless servers, a load balancer, shared session storage, and a plan for scheduled jobs. Scaling up requires none of that.
- Nothing new to debug. One machine has one set of logs and no partial-failure states — no split brain, no instance running last week’s build.
- Some workloads only scale up. A single query that needs 40 GB of working memory to sort needs a machine with 40 GB. Adding a second small server does not help it.
- It’s often cheaper than the engineering. A month of a larger instance usually costs less than a week of the work needed to shard something.
Where it runs out
Two limits eventually bite.
The first is physical. Instance sizes stop at some maximum, and long before that the pricing turns unfriendly — the top-end machine is frequently more than twice the price of the one at half its size, so your cost growth rate outpaces the capacity you’re buying. Adding cores also stops helping once the workload is bound by something else, usually disk or the fact that a single query only parallelizes so far.
The second is availability. One machine is one thing that can fail, and resizing it means downtime. If the service needs to survive a host failure, no instance size fixes that — you need more than one machine, and that’s a horizontal problem regardless of budget.
In practice
For a BI tool instance, scaling up is often the right answer for a long time: memory is what usually runs short, since result sets and query processing live in the application’s heap, and a bigger box solves it directly. For an analytical database, scaling up buys you room while your data grows, but at some point the workload wants a distributed engine.
The realistic pattern is not either/or. Scale up until the cost curve or the availability requirement makes it a bad deal, then scale out — and run a few larger instances behind a load balancer rather than dozens of tiny ones. Watch resource utilization before resizing: buying more CPU when the machine is actually waiting on disk is a common and expensive mistake.
Key article
Related terms
Put it to work
- Cloud cost analytics — Overview
- Infrastructure cost dashboard — Dashboard
- Cost growth rate — Metric
