Skip to main content
Choosing a sharding strategy depends primarily on the database technology you already run and the shape of your workload. Below is a concise decision guide to help you pick the right sharding approach for common scenarios.
  • If you already run MySQL, use Vitess — it layers sharding and routing on top of MySQL.
  • If you run Postgres, use Citus — it extends Postgres with distributed capabilities.
  • If you’re starting new on AWS and mostly perform single-key lookups, consider DynamoDB.
  • For very high write throughput distributed across many machines, consider Cassandra.
  • For document-oriented workloads where entire documents move between shards naturally, consider MongoDB.
A dark-themed slide titled "Which one?" showing five cards that map workloads to databases: MySQL → Vitess, Postgres → Citus, single-key lookups → DynamoDB, heavy writes → Cassandra, and documents → MongoDB. Each card includes icons and arrows linking the use case to the recommended technology.
Quick decision reference Chirp is a relational app (tables, rows, SQL), so adding Vitess or Citus is a natural fit depending on whether you run MySQL or Postgres. These systems take over routing, resharding (moving data between shards), and colocating related rows — responsibilities you otherwise implement manually — so your existing user_id key and table schemas remain usable. What the sharded database will do for you
  • Routing: directs queries to the correct shard based on shard key.
  • Resharding: assists with moving data between shards.
  • Colocation: keeps related rows together to reduce cross-shard joins.
What remains the application’s responsibility
  1. Shard key selection — the database won’t pick your key for you. We chose user_id.
  2. Keeping queries targeted — any query missing the shard key (for example, “everyone who joined between two dates”) triggers scatter-gather across shards.
  3. Hotspot mitigation — the database won’t automatically smooth a leader’s write hotspot; you’ll need caching, request routing, or techniques such as salting.
  4. Denormalization and copy maintenance — if you keep copies or denormalized rows (e.g., cached profiles), your application must update every copy when source data changes.
In short: a sharding-capable database handles routing and movement, but choosing the shard key and keeping queries and data layouts efficient stays with you.
A dark-themed infographic illustrating database sharding: an app routes a user_id to one of four shards (Shard 0–3). Side notes list what the database handles (routing, moving) and sharding concerns like shard key, targeted queries, hotspots, and updating copies.
Sharding is a high-cost, high-impact architectural change. It alters how every query and table behaves and makes the shard key difficult and expensive to change later — changing the key typically requires moving most rows to new shards. Before you shard, exhaust cheaper and reversible options:
  • Scale the primary vertically (bigger machine).
  • Add read replicas to offload reads.
  • Introduce an application cache to reduce read pressure (e.g., cache Lina’s posts).
Three practical, production-ready signals that indicate it’s time to shard
  • Write throughput has saturated a single primary — replicas only help reads.
  • Dataset size makes backups or schema migrations (like adding a column) prohibitively long or unsafe.
  • The working set no longer fits in memory on the largest rentable machine, causing increased disk I/O and slow reads.
If the only problem is slow reads, replicas and caching usually suffice — they reduce load without splitting tables. In this guide, sharding is treated as the right step when writes have hit the ceiling; that’s the most common and defensible trigger for sharding in production.
A dark-themed diagram titled "When should you shard at all?" showing an app, cache, a primary database and two replicas with arrows between them. Alongside are three bullet reasons to shard: "writes hit the ceiling," "too big to back up," and "won't fit in memory."
Sharding permanently reshapes your system. Delay it until necessary and invest most effort in picking the right shard key, keeping queries targeted, preventing hotspots, and ensuring your application consistently maintains any denormalized or replicated copies.
Links and references

Watch Video