Home / Data Centers / Horizontal vs. Vertical Scaling: Everything You Need to Know
You have two options when expanding an IT system to meet the demand of an increased load: horizontal or vertical scaling. Both strategies involve adding new resources (RAM, CPU, hard disks, etc.) to computing infrastructure, but the two come with different benefits and challenges.
So, when demand for your app or website goes up, should you scale horizontally or vertically?
This article offers a detailed comparison of horizontal and vertical scaling, two distinct strategies for adding more resources to an IT system. Read on to learn the differences between the two scaling models and see which one is a better fit for your use case.
Scalability is the capability of a computer system (hardware or software) to continue functioning well when it changes in size or volume. A scalable system seamlessly expands to meet the increased customer demand and larger workloads without impacting service quality.
Every IT system (website, app, database, etc.) has a scalability limit, a point at which it can no longer handle extra demand without issue. The lack of resources to meet the traffic needs or user requests causes latency, while some extreme overloads lead to server crashes and downtime.
The only way to push a system's scalability limit is to add more computing resources (i.e., to scale a system). A sysadmin scales a machine by improving one (or more) of the following:
You can also scale a system down. This process involves lowering the capacity to adjust to a smaller demand, typically to eliminate unnecessary spending and reduce IT expenses. Scaling down is common in cloud computing as sysadmins look to control cloud computing costs by optimizing resource utilization.
Scaling (up or down) is either permanent or temporary. Temporary scaling is the go-to option when a company expects a short-term burst of traffic or activity that will pass over time (e.g., when an ecommerce website prepares for the holiday season).
There are two strategies for expanding a system's capabilities:
Let's take an in-depth look at both scaling models and see what they offer.
Horizontal scaling (or "scaling out") refers to adding more nodes to a system's resource pool to meet the increased demand. You do not improve the specifications of the existing machine—instead, you add more same-size servers to the cluster and share the workload across more devices.
Scaling out enables a sysadmin to combine the power of multiple machines to meet the current load demands. Nodes do not have to be in the same data center, they do not have to be in the same region even.
Horizontal Scaling Disadvantages
Here's a simple analogy for explaining what scaling out means. Let's say you plan to drive around with three buddies in a four-seated car. What do you do if an extra three people want to tag along?
Scaling out is the equivalent of getting another identical four-seated car and going on a ride as a two-vehicle convoy.
Vertical scaling (or "scaling up") refers to adding more hardware to an existing machine so that you run the same workload on better specs. For example, if a server requires more processing power, vertically scaling the device would mean upgrading its CPU. Other examples of vertical scaling include:
In some cases, vertical scaling means replacing a machine entirely to cope with increased demand.
This type of scaling was the go-to option back when we had monolithic apps that had to run on a single server. Nowadays, vertical scaling is a common choice for small-to-mid-size companies that see a noticeable difference in performance or UX from an upgraded machine.
Vertical Scaling Disadvantages
To follow up on our car analogy, scaling up would mean upgrading your existing four-seated car to a van that fits all the passengers looking for a ride.
The horizontal vs vertical scaling table below offers a head-to-head comparison of the two scalability models:
| Point of comparison | Horizontal scaling (scaling out) | Vertical scaling (scaling up) |
|---|---|---|
| How the scaling works | You add new same-size servers to an existing pool of machines | You upgrade components of an existing server (or get a new device to substitute the current one) |
| Process complexity | High (requires load balancing and code for managing data consistency) | Low (turn off the server, take out the old component, set up the new one, and restart the device) |
| Overall cost | High (you purchase new servers every time you scale) | Low (if you're buying only one or two new components) |
| Load balancing | Yes | No |
| Single point of failure | No | Yes |
| Performance concerns | Nodes communicate over network calls (RPC), which slows down system performance | Everything runs on the same server, which boosts performance |
| Data storage | You distribute data across multiple nodes | All data lives on the same server |
| Data consistency | An issue since data moves between different nodes | Data resides on one system, so there's less chance for dirty reads or dirty writes |
| An upper limit for scalability | No (you can always add more machines) | Yes (each machine has a threshold for RAM, storage, and processing power) |
| Downtime during scaling | No | Yes |
| Rapid growth handling | Highly flexible (even automatic in some cases) | Manual and inflexible |
| Risk of unused resources | Low | High |
| Required code reworks | Requires breaking a sequential piece of logic so that workloads run in parallel across multiple machines | The logic does not change (you just run the same code on a higher-spec device) |
| Ability to scale down | Yes | Not without taking the machine offline and removing components |
| Database programs | Cassandra, Google Cloud Spanner, and MongoDB | MySQL and Amazon RDS |
If the hands-on approach to scaling looks too complex, consider switching to a cloud-based infrastructure. One of the main advantages of cloud computing is that you scale on-demand, so you offload all scalability-related tasks to the provider and get to focus on other business fronts.
Both scaling out and up are worthwhile strategies that fit different use cases and business priorities:
Here are the main factors to consider when choosing a scaling model:
phoenixNAP's Bare Metal Cloud provides automated server deployments with preconfigured dedicated servers suitable for any workload. BMC is cloud native, can be managed via API and CLI and offers instantaneous horizontal scaling.
Horizontal scaling is gaining popularity due to its better resource utilization and uptime guarantees. However, this trend does not mean you should always go for scaling out—some use cases are still a much better fit with scaling up. Evaluate each workload and data set's fit in a vacuum and always consider both scaling models before committing to a system design.
Andreja is a content specialist with over half a decade of experience in putting pen to digital paper. Fueled by a passion for cutting-edge IT, he found a home at phoenixNAP where he gets to dissect complex tech topics and break them down into practical, easy-to-digest articles.
