Sharding distributes data across multiple database servers (shards) to scale beyond single-server limits. Shard key determines which shard a row goes to. Hash sharding: even distribution, no range queries across shards. Range sharding: efficient range queries, risk of hotspots. Consistent hashing allows adding shards with minimal data movement. The biggest operational challenge is resharding (rebalancing data when shard count changes) and cross-shard transactions.
Adding a shard with consistent hashing minimises data movement.
Your shard key is baked into your data model forever. A bad shard key (like timestamp) creates hotspots that are impossible to fix without full data migration. Evaluate carefully before your first write.
If your queries are date-based, prepend a random prefix: shard_key = rand(0,9) + date. Distributes temporal writes evenly across shards while keeping related date data close.
Cross-shard joins and transactions are an order of magnitude more expensive. Denormalize data to co-locate related records on the same shard. If orders belong to users, shard both by user_id.
Sign in to share your feedback and join the discussion.