Partitioning: Vertical and Horizontal Sharding

In one line: replication gives you copies; partitioning gives you capacity. It is also the one database decision that is genuinely expensive to reverse, because the partition key determines the physical layout of every row.

Why partition

As data volumes and concurrent traffic grow, single-node databases reach scalability limits and latency and throughput degrade. Traditional databases offer robust features — range queries, secondary indexes, ACID transactions — but maintaining those in a distributed environment is challenging.

At some point a single node becomes the bottleneck. The alternatives all cost something:

The hotspot problem

Partitioning must be balanced. If one partition receives significantly more data or queries it becomes a hotspot — a single congested node absorbing the majority of traffic, degrading the whole system.

There are two ways to shard.

When do you actually need this?

The lesson so far explains how to partition. The question that comes first, and that separates a proportionate answer from an over-engineered one, is at what point a single node stops being enough — because sharding is the most expensive thing in this chapter and the numbers are higher than most people assume.

Rough orders of magnitude for a well-tuned single relational node on decent hardware:

simple inserts            ~5,000 / second / core
updates touching indexes  ~1,000-2,000 / second / core
complex transactions      hundreds / second
table size                gets unwieldy past ~100M rows
working set               must fit in RAM, or performance falls off a cliff

These are not hard limits, and they move with hardware and tuning. They are useful because they set the shape of the answer: a system doing a few thousand writes a second does not need sharding, and saying so is a stronger answer than sharding reflexively.

The order to exhaust before sharding, cheapest first:

The step change is at the bottom. Everything above sharding is operational — you can do it without the application knowing. Sharding is architectural: cross-shard joins stop working, transactions can no longer span shards without a distributed protocol, and every query has to either carry the shard key or fan out. That is why it belongs last, and why the strongest version of this answer names the ladder rather than jumping to the bottom rung.

Vertical sharding

Vertical sharding moves specific tables or columns to different database instances or physical servers. It is often used to separate columns containing large text or binary data (blobs) from the main table to improve retrieval speed.

If an Employee table contains a large photo blob, split it into a lighter Employee table holding metadata and an EmployeePicture table holding the blob. Both retain the primary key EmployeeID so the data can be reconstructed efficiently.

Vertical sharding is often manual and static; horizontal sharding is better suited to automation and dynamic scaling.

Horizontal sharding

Horizontal sharding divides a table row-wise into multiple smaller tables. Each partition is a shard. Two primary strategies:

Key-range-based sharding

Each partition is assigned a continuous range of keys. An Invoice table partitioned on Customer_Id puts specific ID ranges in different partitions.

Shard 1: Customer_Id 1-2      Shard 2: Customer_Id 3-4

When multiple tables are linked by foreign keys, shard them on the same partition key so related data — a Customer and their Orders — stays on the same shard, keeping retrieval local.

Common design techniques for multi-table sharding:

Hash-based sharding

A hash function determines the partition: compute the hash of the key and take the modulus of the partition count.

partition = hash(key) mod n          where n = number of nodes

With n = 4, keys whose hash mod 4 equals 2 go to node 2, and so on. This randomizes placement to ensure uniform distribution.

The two strategies are exact opposites: key-range preserves locality and risks skew; hashing destroys locality and guarantees spread.

How many shards do you need?

Estimate from node capacity. If a single node handles 50 GB and the database is 10 TB:

Number of shards = Database size / Size of a single shard
                 = 10 TB / 50 GB
                 = 200 shards

This is the back-of-the-envelope method from Foundations applied to storage — and it's a good habit to state the shard count out loud, because it tells the interviewer whether you're designing for 4 nodes or 400.

Consistent hashing

Consistent hashing maps both servers and data keys onto positions on an abstract circle, or ring. This allows nodes to scale with minimal data movement, preserving performance.

Its disadvantage is real and has a standard fix — virtual nodes, where each physical server owns many small arcs of the ring rather than one large one, which smooths the distribution. The Key-Value Store chapter covers that mechanism in depth.

Interview signal by level

Next: what happens when you add or remove a node.