Database sharding: when to shard and how to do it without regret

Sharding distributes data across multiple database instances to handle data that exceeds a single server's capacity. It's one of the most significant architectural decisions you can make, and it's almost always harder than you expect.

Shard when you have to, not when you want to. Most applications will never need to shard. PostgreSQL can handle hundreds of gigabytes on a single node with proper tuning. Before considering sharding, exhaust all other options: optimize queries, add indexes, increase instance size, use read replicas, and implement caching.

The sharding key determines everything. Choose a key that distributes data evenly across shards and aligns with your query patterns. The most common choice is the user ID or tenant ID. All queries that include the sharding key are efficient because they go to a single shard.

Range-based sharding splits data by ranges of the sharding key. It's simple to implement. The problem is hot spots if most of your users are in one range, that shard gets all the traffic. Consistent hashing distributes data more evenly.

Re-sharding changing the number of shards is painful. Traditional sharding requires moving large amounts of data during re-sharding. The standard approach is to create a new set of shards and migrate data gradually.

Consider whether you actually need application-level sharding. Vitess and Citus provide transparent sharding for MySQL and PostgreSQL respectively. They handle routing, re-sharding, and query distribution without application changes.

Document your sharding strategy thoroughly. Every developer on the team needs to understand the sharding key, how to add new shards, and how to handle queries that span shards. Sharding requires ongoing maintenance and monitoring.

-

Rizwan Saleem | https://rizwansaleem.co