Scalability

Scalability is the ability of a system to handle an increasing workload, either by adding more resources or by making the existing ones bigger.

Horizontal Scaling

Horizontal scaling, also called scaling out, means adding more machines or nodes to a system so the workload is distributed evenly across them.

No single node has to absorb the growth. More requests arrive, more machines share them. This suits distributed systems well. Capacity can be added while the system runs, which makes it a cost-effective way to handle workloads that rise and fall, and having many machines is what makes high availability possible in the first place.

Cassandra and MongoDB are good examples. Both are built so you add machines to meet growing demand.

Vertical Scaling

Vertical scaling, also called scaling up, means increasing the capacity of an individual node by upgrading its hardware: more CPU, more memory, more storage.

The same single machine now handles more work. MySQL is a good example. Moving from a smaller machine to a bigger one is a straightforward way to get more capacity, and the process usually involves downtime.

Scaling out adds more machines beside the existing ones, while scaling up replaces one machine with a bigger one.

The Difference That Decides It

Horizontal scaling is easier to do dynamically. You add machines to the pool that is already running.

Vertical scaling is bounded by a single server's capacity. Growing past that ceiling usually means downtime, and there is an upper limit you eventually hit no matter what you spend.

Read the last two rows together, because that is where the risk lives. Relying only on vertical scaling has two problems at once: there is a physical ceiling on how big one machine can get, and putting everything on that one machine creates a single point of failure. The system gets faster right up until the moment it is completely down.

MySQL is an example here, not a rule

The examples above line up as NoSQL on one side and relational on the other, and that is not where the real line sits. Relational databases can be scaled horizontally, and several widely used systems do exactly that:

• Vitess puts a sharding layer in front of MySQL and routes each query to the right shard. YouTube and Slack run on it.
• Citus is an extension that turns PostgreSQL into a distributed database by spreading tables across nodes.
• CockroachDB, Google Spanner and YugabyteDB are built to scale out from the start, while still speaking SQL and offering transactions.

What is true is that scaling a relational database out takes more work than scaling out a system designed for it from the beginning. Once the rows of one table live on different machines, a join across shards has to pull data over the network, and a transaction touching two shards needs a distributed commit. Both are slower and more complicated than their single-machine versions. Cassandra sidesteps the problem by not offering cross-node joins at all, which is a restriction rather than a magic property.

So the accurate sentence for an interview is not "relational databases cannot scale horizontally." It is "sharding a relational database costs me cheap joins and cheap transactions across shards, so I would either choose shard keys that keep related rows on the same node, or use a database built to scale out."

Real systems combine the two. A service can run on many machines and also give each machine more CPU or memory when individual tasks are heavy. Scaling both ways at once is sometimes called diagonal scaling: bigger machines, and more of them, for the same workload.

Key takeaway: Scalability is handling more work by adding resources. Horizontal scaling adds machines and spreads the workload across them, which is the approach distributed systems are built for. Vertical scaling makes one machine bigger, which is simple but limited by that machine's ceiling, usually requires downtime, and concentrates everything into a single point of failure.