When should I shard my database?

Shard when you have exhausted vertical scaling, read replicas, caching, and query optimization, and your database still cannot handle the load. Most applications never need sharding — it is a last resort due to its operational complexity.

What is a hot spot in sharding?

A hot spot occurs when one shard receives disproportionately more traffic or data than others, typically due to a poorly chosen shard key. For example, sharding by country puts most data on the US shard.

Can I change the shard key later?

Changing the shard key requires migrating all data across shards — effectively resharding the entire database. This is extremely disruptive, which is why getting the shard key right upfront is critical.

Database Sharding Explained

Horizontal data partitioning across multiple databases — the scaling technique for when a single server is no longer enough.

Database Sharding

Database sharding is a horizontal scaling technique that partitions data across multiple database instances (shards), where each shard holds a subset of the data, enabling the system to handle more data and traffic than a single database can support.

Explanation

Vertical scaling (bigger server) has hard limits — eventually, no single machine can handle the data volume or query throughput. Sharding distributes data horizontally across multiple database instances. Each shard is a fully functional database containing a subset of the total data, determined by a shard key (e.g., user ID modulo number of shards, geographic region, or date range). The shard key is the most critical design decision. A good shard key distributes data evenly (avoids hot spots), keeps related data together (minimizes cross-shard queries), and aligns with common query patterns. A poor shard key creates unbalanced shards, forces expensive scatter-gather queries, or requires frequent resharding as data grows. Sharding introduces significant complexity: cross-shard queries require scatter-gather operations, cross-shard transactions need distributed coordination (2PC or Saga), resharding when adding or removing shards requires data migration, and operational overhead multiplies with each shard. Many applications should exhaust simpler scaling options (read replicas, caching, query optimization, vertical scaling) before considering sharding.

Bookuvai Implementation

Bookuvai recommends sharding only for applications that have exhausted simpler scaling approaches. When sharding is necessary, we design the shard key based on access pattern analysis, implement application-level routing, and use consistent hashing for shard assignment. Our data migration tooling supports zero-downtime resharding when adding capacity.

Key Facts

Shard key design is the most critical and hardest-to-change decision
Hot spots occur when one shard receives disproportionate traffic
Cross-shard queries and transactions add latency and complexity
Consistent hashing minimizes data movement when adding shards
Exhaust vertical scaling, read replicas, and caching before sharding

Related Terms

Frequently Asked Questions

When should I shard my database?: Shard when you have exhausted vertical scaling, read replicas, caching, and query optimization, and your database still cannot handle the load. Most applications never need sharding — it is a last resort due to its operational complexity.
What is a hot spot in sharding?: A hot spot occurs when one shard receives disproportionately more traffic or data than others, typically due to a poorly chosen shard key. For example, sharding by country puts most data on the US shard.
Can I change the shard key later?: Changing the shard key requires migrating all data across shards — effectively resharding the entire database. This is extremely disruptive, which is why getting the shard key right upfront is critical.