Atlas: choose a shard key using cardinality, frequency, and monotonicity

TL;DR: The shard key is the hardest decision in sharding and nearly immutable. Evaluate candidate fields on the three axes before committing. Verify After sharding, watch chunk distribution and per-shard write load.

The fix

TL;DR: The shard key is the hardest decision in sharding and nearly immutable. Evaluate candidate fields on the three axes before committing. Verify After sharding, watch chunk distribution and per-shard write load.

Choose a shard key

A bad shard key gives you jumbo chunks or a hot shard, and fixing it later means a reshard. Evaluate candidates on three axes:

The three axes

1. Cardinality: how many distinct values? High cardinality lets MongoDB split into many chunks. Low-cardinality fields (status, region) cap how far you can scale.
2. Frequency: how often does one value repeat? A high-cardinality field where one value owns 80% of documents still creates a jumbo chunk.
3. Rate of change: is it monotonic (timestamps, ObjectIds, counters)? Monotonic keys send all new writes to the max-key chunk on one shard: the classic hot shard.

Patterns

• Hashed shard key ({ userId: "hashed" }): spreads writes evenly, great for write scaling. Weak for range queries, since hashing destroys order.
• Ranged shard key on a high-cardinality, non-monotonic field: good for range queries and even distribution.
• Compound key ({ tenantId: 1, createdAt: 1 } style, or hashed prefix): isolates tenants and spreads within them. Match it to your actual query patterns so mongos can target shards.

Rules

• Measure, do not guess: run distinct counts and top-value frequency analysis on production-shaped data.
• Never shard on a pure timestamp or ObjectId with a ranged key unless write volume is tiny.
• Remember the key is effectively immutable per document and changing it later requires resharding the collection.

Verify

After sharding, watch chunk distribution and per-shard write load. Even spread under real traffic is the passing grade.

When to use this

• This covers exactly what the title says: Atlas.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Atlas; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Atlas behavior.

Shard key selection criteria (cardinality, frequency, rate of change) and hashed vs ranged strategies per https://www.mongodb.com/docs/manual/sharding/, verified 2026-09-26.