What Is Sharding?
Database Sharding
Sharding splits a database into smaller pieces (shards) distributed across multiple servers. Each shard holds a subset of the data — e.g., users A-M on Server 1, N-Z on Server 2. It's how databases scale beyond what a single server can handle.
How Sharding Works
When your single PostgreSQL server can't handle the load, you shard: split the users table across multiple servers by user_id hash. Each server handles a fraction of the queries. MongoDB and Cassandra have built-in sharding. PostgreSQL uses Citus extension.
Key Concepts
- Shard Key — The column used to determine which shard holds each row — choosing the right key is critical for even distribution
- Cross-Shard Queries — Queries spanning multiple shards are expensive — design your shard key to keep related data together
- Rebalancing — Moving data between shards when load becomes uneven — automated in managed databases
Frequently Asked Questions
When should I shard?
Most applications never need sharding. Optimize queries, add indexes, use read replicas, and vertically scale first. Shard only when a single server genuinely can't handle the load — typically millions of rows with high write throughput.