Skip to main content
Sharding is the practice of splitting your rows across multiple machines so that no single server stores the entire dataset. This approach—also called horizontal scaling—lets you add many ordinary machines instead of upgrading a single, larger machine. Each machine stores a subset of the rows; that subset is called a shard. A shard is simply one machine (or logical partition) holding a portion of the table rows. All shards typically share the same table schema (same columns and layout). For example, every shard in a social app might have the columns: user_id, username, and follower_count. Leo’s row will exist entirely on one shard, and Chris’s row will exist entirely on another, but both shards use the same schema.
A schematic diagram of four database shards (Shard 0–3) shown as cylinder icons with tables beneath listing user IDs, usernames and follower counts. Below the tables are highlighted user profile cards (e.g., Leo and Chris) linked to entries in the shards.
A common simple sharding rule is to use the user ID modulo the number of shards. For example, with four shards:
  • Compute user_id % 4 to get a remainder of 0, 1, 2, or 3.
  • Map that remainder to a shard:
    • 0 → shard 0
    • 1 → shard 1
    • 2 → shard 2
    • 3 → shard 3
Example calculations:
  • 1 % 4 = 1 → shard 1
  • 4 % 4 = 0 → shard 0
  • 7 % 4 = 3 → shard 3
You can express this logic in simple code:
Table: remainder → shard mapping Why teams shard: a single primary database has a finite write throughput. By splitting data across four machines, Chirp effectively has four primaries; each can accept writes for the rows it stores. If write capacity is still insufficient, you can add more shards (e.g., 8, 16, …) and distribute rows across them. This horizontal scaling increases write throughput by distributing load.
Pick a shard key that balances traffic. A good shard key spreads writes and reads evenly; a poor one can create “hot” shards. Consider user ID hashing or composite keys to avoid hotspots.
Splitting data introduces new challenges. One immediate question: when a request arrives that needs Alan’s data, how does the
A schematic diagram of a mobile client ("Leo") sending a request to an app/server that routes queries to four database shards (Shard 0–3), each showing stored rows. The diagram notes the app "needs Alan's row" and marks each shard as primary.
system know which shard holds Alan’s row? The answer depends on how you partitioned the data. Common strategies include: Routing decisions can be implemented in different places:
  • Application layer: the app computes the shard and directs the query to the correct database.
  • Middleware/proxy: a routing service sits between app and databases and forwards requests.
  • Lookup service: a small directory service that the app queries to find the shard for a particular key.
Each approach has trade-offs in complexity, latency, and operational cost. Later sections will dig into re-sharding, cross-shard queries, transactions, and patterns for migrating data between shard layouts. Further reading:

Watch Video