Billions of bits of data are generated every moment across the globe, and corporates now find data as their most essential and valuable asset. Considering a typical organization database, its size will grow day by day, and every such database needs to be scaled from time to time to address the storage and processing needs. So, a database you use must be scalable to be available all the time. When the database memory gets drained or cannot handle multiple simultaneous requests, it is not scalable.

What is scalability?

Scalability can be defined as the capacity of a system, process, or a network to proportionately expand and handle the increasing volume of work to accommodate the growth. Primarily, scaling can be categorized into:

• Vertical and,
• Horizontal Scaling.

Scalability vs. elasticity

Elasticity can be defined as the extent to which an existing system can stretch to adapt the workload changes by provisioning or de-provisioning the resources based on demand. This is by ensuring that the available resources may match the demands at any given point in time. A system can be called elastic if it can be scaled easily to accommodate all demanding resource needs.

Let us further discuss the two scaling types as enumerated above.

1. Vertical Scaling (scale-up)

This is an apt mode of scaling if the given database cannot handle a huge data volume. Say, for example, if you run a database server having 10GB memory capacity, which is exhausted. To handle more data volume, you may have to buy another expensive server, which may have a memory space of 1 or 2 TB. Shifting to this server will enable you to handle more data. This approach is known as ‘Vertical Scaling.’ So, simply this the process of getting a bigger capacity server. The process may also be adding a better performing CPU or more disk power to expand the storage.

The scale-up database’s effectiveness may depend on the application it is used for and the type of usage. You can consider Instagram, for example. Initially, there was only a limited number of people on it as users. So, it would have been run on a single limited capacity server. But see its current state, there are billions of people using this app. So, a limited storage server may not meet the need.

As pointed out by RemoteDBA, another important thing when it comes to data servers is that the data should be queried. If the case is that a single node handles a lot of such queries, it may not give any proper speedy response. So, in case of huge applications with a lot of queries to handle, vertical scaling is not a choice. On the other hand, for base-line applications to handle only a limited number of users and low volume queries, vertical scaling can be considered to expand the server storage. Relational databases tend to use vertical scaling.

Pros of vertical scaling

• Vertical scaling is very simple and straight forward as the entire data is in a single server. So, there is no risk of managing multiple instances simultaneously.
• For each update, you have more memory power and speedy RAM.
• There is no need for any code change during scaling up. No need to change the implementation also.

Cons of vertical scaling

• It may fail to respond to simultaneous multiple queries.
• More downtime is a higher possibility if the server exceeds the specified load.
• It may be more expensive, and the hardware resources may also be costly.

2. Horizontal Scaling (Scaling Out)

As the name suggests, horizontal scaling increases the capacity of the data server by horizontally adding more machines. It will help divide the data sets and logically distribute them over different servers called shards. Every single shard can act as independent databases, and process queries faster. Unlike vertical scaling, there is no need to buy another bigger capacity server here, but you can add a hundred 10 GB servers to increase the capacity to 1 TB.

Through vertical scaling, you can increase the memory and power of a single server, whereas horizontal scaling help increases the number of systems. Let us take the same Instagram example, as we discussed above. Instead of vertical scaling, we use multiple machines of the same power and size to get connected to the preceding server horizontally as the data volume increases. In this, one server may store the user IDs, another server the profile info, another store the user stories, and another one to store the images. No, queries are addressed to the specific server, which may reduce the load on the servers as a whole and return better performance.

If your application needs to perform a lot of automated transactions at the backend, then it is better to use the vertical scaling mode. However, if your application is meant to allow more redundancy and only involves fewer joins, then the horizontal scale is the choice. The modern-day NoSQL databases tend to rely more on horizontal scaling. However, horizontal scaling is less advisable for the relational database management systems as it relies more on atomicity and consistency rules.

Pros of horizontal scaling

• Cheaper compared to vertical scaling.
• It ensures better performance and can lessen the load.
• Compared to vertical screening, the downtime chances are very less.
• Fault tolerance is better.
• Better resilience

Cons of horizontal scaling

• Making the joins are quite difficult as horizontal connections involve more cross-server communications.
• Less consistency. So, it may not be ideal for related banking transactions or something needed to be executed simultaneously
• We may not be able to categorize each of the features to a specific server. For example, the server for images may sometimes take more space than what is available in a single server.

So, we can see that vertical and horizontal scaling each serve various purposes. So, when your need is for scaling the existing database to accommodate more data or to handle an increasing number of queries, you may do a thorough analysis as to which one suits your needs and go ahead with the best strategy.