> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Which One and When to Shard at All

> Practical guide to when to shard databases, choosing shard keys, and picking technologies like Vitess, Citus, DynamoDB, Cassandra, or MongoDB for common workloads

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](https://www.mysql.com/), use [Vitess](https://vitess.io/) — it layers sharding and routing on top of MySQL.
* If you run [Postgres](https://www.postgresql.org/), use [Citus](https://www.citusdata.com/) — it extends Postgres with distributed capabilities.
* If you’re starting new on AWS and mostly perform single-key lookups, consider [DynamoDB](https://aws.amazon.com/dynamodb/).
* For very high write throughput distributed across many machines, consider [Cassandra](https://cassandra.apache.org/).
* For document-oriented workloads where entire documents move between shards naturally, consider [MongoDB](https://www.mongodb.com/).

![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.](https://mintcdn.com/kodekloud-c4ac6d9a/U9fTv2NKZBAqmNMH/images/System-Design-Database-Sharding/Sharding-in-Practice/Which-One-and-When-to-Shard-at-All/which-one-workloads-to-databases.jpg?fit=max\&auto=format\&n=U9fTv2NKZBAqmNMH\&q=85\&s=d19163c0e0f3535c6693a4cf8312b375)

Quick decision reference

| Workload / Constraint | Recommended technology | Why |
| - | -: | - |
| Relational MySQL apps | [Vitess](https://vitess.io/) | Retains MySQL features, adds routing and resharding |
| Relational Postgres apps | [Citus](https://www.citusdata.com/) | Scales Postgres horizontally with distributed queries |
| Single-key lookups on AWS | [DynamoDB](https://aws.amazon.com/dynamodb/) | Managed, single-digit ms lookups and predictable scaling |
| Extremely heavy distributed writes | [Cassandra](https://cassandra.apache.org/) | Designed for multi-master write scalability |
| Document-centric workloads | [MongoDB](https://www.mongodb.com/) | Native document model and shard-aware routing |

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.](https://mintcdn.com/kodekloud-c4ac6d9a/U9fTv2NKZBAqmNMH/images/System-Design-Database-Sharding/Sharding-in-Practice/Which-One-and-When-to-Shard-at-All/database-sharding-userid-routing-infographic.jpg?fit=max\&auto=format\&n=U9fTv2NKZBAqmNMH\&q=85\&s=643b2a64ee55586d9936e11d4e136969)

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."](https://mintcdn.com/kodekloud-c4ac6d9a/U9fTv2NKZBAqmNMH/images/System-Design-Database-Sharding/Sharding-in-Practice/Which-One-and-When-to-Shard-at-All/when-to-shard-writes-backup-memory.jpg?fit=max\&auto=format\&n=U9fTv2NKZBAqmNMH\&q=85\&s=ed9a40202b7893c1a0be00ac06fb389d)

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

* [Vitess — scaling MySQL](https://vitess.io/)
* [Citus — scaling Postgres](https://www.citusdata.com/)
* [DynamoDB — AWS managed key-value & document store](https://aws.amazon.com/dynamodb/)
* [Cassandra — distributed wide-column store](https://cassandra.apache.org/)
* [MongoDB — distributed document database](https://www.mongodb.com/)

> **[Watch Video](https://learn.kodekloud.com/user/courses/database-sharding/module/1a567ebf-0997-46eb-9a16-b6b2c530bd5f/lesson/c237fb38-5152-4591-873f-ca950134c02c)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.