Course contentsShow
← Databases & SQL
Lesson 1217 of 1,95311. NoSQL and Document ModelsFree lesson

The Dangers of Poor Shard Key Selection

Analyze the performance impact of monotonically increasing shard keys.

In this lesson, you will learn why using monotonically increasing values as shard keys creates a performance bottleneck known as a "hot shard."

The Problem with Time-Based Keys

When you shard a database, you distribute your documents across multiple physical servers (shards) based on a specific field, called the shard key. A common, yet dangerous, choice for this key is a monotonically increasing value, such as a timestamp or an auto-incrementing integer (like an _id generated by ObjectId if you aren't careful).

Because these values are always increasing, every single new document you write will fall into the "highest" range of your data distribution.

Imagine you have three shards:

  • Shard A: Handles ranges 0–100
  • Shard B: Handles ranges 101–200
  • Shard C: Handles ranges 201–300

If you insert a document with a timestamp of 1670000000 (and your system is currently in that range), every single insert is funneled exclusively to Shard C. Shards A and B sit completely idle, while Shard C becomes overwhelmed by the entire write load of the application.

Why This Hurts

This creates a Hot Shard scenario. Your cluster fails to achieve horizontal scale because your effective throughput is limited to the capacity of a single machine. Even though you have three servers, you are essentially still running on one, while the others remain underutilized.

Instead of a smooth, balanced distribution, your data flow looks like this:

Time T1 -> Write to Shard C
Time T2 -> Write to Shard C
Time T3 -> Write to Shard C
...

The Alternative

To prevent this, you should select a shard key with high cardinality and a more random distribution—such as a user_id or a hashed value of a common field. By ensuring that incoming writes are scattered randomly across all available shards, you allow the database to parallelize the write load and maximize the hardware investment of your entire cluster.

Key Takeaway: Avoid using monotonically increasing values as shard keys, as they force all write operations onto a single shard, creating a performance bottleneck that prevents true horizontal scaling.