Database Sharding & Partitioning

The Limits of Vertical Scaling

When a relational database becomes the bottleneck, the first instinct is Vertical Scaling: buying a bigger server with more RAM and CPU. However, vertical scaling has physical limits and becomes exponentially expensive. The ultimate solution is Horizontal Scaling via Sharding.

What is Sharding?

Sharding involves splitting a single logical database across multiple physical database nodes (shards). For example, in a multi-tenant SaaS, you might put Users 1-1000 on Database A, and Users 1001-2000 on Database B.

The Sharding Key (Shard Key)

Choosing the right shard key is the most critical decision in database architecture. If you shard by Country, and 90% of your users are in the US, one shard will be overwhelmed while the others sit idle (a "hot spot"). A good shard key distributes data uniformly across nodes.

Consistent Hashing

If you use a simple modulo hash (e.g., hash(user_id) % num_servers), adding or removing a database server changes the modulus, requiring you to re-shuffle nearly all your data.

Consistent Hashing solves this by mapping both the servers and the data keys onto a conceptual circle (a hash ring). When a new server is added, it only takes over a portion of the keys from its immediate neighbor on the ring, minimizing data migration and preventing downtime.