Database Sharding

Database sharding is a horizontal scaling technique that splits a dataset into pieces called shards and spreads them across separate database servers. Each shard holds a subset of the rows, chosen by a shard key.

Why it matters

A single server eventually hits limits on disk, memory, or write throughput. Sharding lets capacity grow by adding servers. It adds real complexity: cross-shard joins and transactions become hard, rebalancing data is disruptive, and a poorly chosen key creates hot spots. Most teams delay it until simpler options like indexing, caching, and replicas are exhausted.

Example

shard = hash(user_id) % 4

user_id 1001 -> shard 1
user_id 1002 -> shard 2
user_id 1003 -> shard 3

All data for one user lives on one shard, so common queries touch a single server.

Common mistakes

• Choosing a shard key with uneven distribution, so one shard takes most of the traffic.
• Sharding too early, long before a single well-tuned server is the bottleneck.
• Forgetting that queries without the shard key must be sent to every shard.

Related

• Database partitioning
• Database replication
• CAP theorem

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.