Database Sharding Cheat Sheet

Covers horizontal partitioning strategies, shard key selection, routing, and rebalancing for scaling databases across multiple nodes.

2 PagesAdvancedMar 12, 2026

Sharding Strategies

Common approaches to splitting data across shards.

Range-based sharding- Partitions data by key ranges (e.g., user_id 1-1M on shard A); simple but prone to hotspots on sequential keys
Hash-based sharding- Applies a hash function to the shard key to evenly distribute rows; loses range-query locality
Directory-based sharding- A lookup service maps each key to its shard, allowing flexible rebalancing at the cost of an extra hop
Geo-sharding- Partitions by region/location to reduce latency and satisfy data-residency requirements
Consistent hashing- Maps shards and keys onto a hash ring so adding/removing a shard only remaps a fraction of keys
Shard key- The column(s) used to determine which shard a row lives on; picking it wrong causes hotspots or cross-shard joins

Hash-Based Shard Routing

Route a request to its shard using a hash of the key.

python

import hashlibdef get_shard(user_id: str, num_shards: int) -> int:    # Consistent hash of the key mod number of shards    digest = hashlib.md5(user_id.encode()).hexdigest()    return int(digest, 16) % num_shards# Route a query to the correct shard connectionshard_id = get_shard("user_42", num_shards=8)conn = shard_connections[shard_id]conn.execute("SELECT * FROM orders WHERE user_id = %s", ("user_42",))

Consistent Hashing Ring

Minimize key remapping when shards are added or removed.

python

import bisectimport hashlibclass HashRing:    def __init__(self, nodes, vnodes=100):        self.ring = {}        self.sorted_keys = []        for node in nodes:            for i in range(vnodes):                key = self._hash(f"{node}:{i}")                self.ring[key] = node                bisect.insort(self.sorted_keys, key)    def _hash(self, key):        return int(hashlib.md5(key.encode()).hexdigest(), 16)    def get_node(self, key):        h = self._hash(key)        idx = bisect.bisect(self.sorted_keys, h) % len(self.sorted_keys)        return self.ring[self.sorted_keys[idx]]

Common Pitfalls

Issues that surface once a sharded system is in production.

Cross-shard joins- Joining rows that live on different shards requires app-level fan-out or a scatter-gather query; avoid by denormalizing
Hotspotting- A poorly chosen key (e.g., monotonically increasing IDs) concentrates writes on one shard
Rebalancing cost- Adding shards without consistent hashing forces a full data reshuffle; plan capacity ahead of time
Distributed transactions- Multi-shard writes need two-phase commit or sagas since native ACID transactions don't span shards
Global secondary indexes- Queries on non-shard-key columns require a separate index service or scatter-gather across all shards

Pro Tip

Pick a shard key with high cardinality and even access patterns (e.g., a hashed user_id), not a monotonically increasing timestamp or auto-increment ID — those funnel all new writes onto the last shard.

Was this cheat sheet helpful?

Database Transactions Cheat Sheet

Database Replication Cheat Sheet