How does MongoDB's configured chunk (range) size affect balancing, and when would you change the default?

## What the setting actually controls The configured range size (still spelled `chunksize` in the settings document) is a **target**, not a hard cap. It governs how large a slice the balancer carves off when it needs to move data, and it is the yardstick for the balance threshold: MongoDB 6.0+ treats a collection as balanced when the difference between the most- and least-loaded shard is under roughly three times this value. Double the range size and you double the imbalance the cluster will tolerate before doing anything. The default is **128 MB** on MongoDB 6.0 and later; earlier versions defaulted to 64 MB. The allowed values run from **1 MB to 1024 MB**. ## Setting it Cluster-wide, it is a document in the `config` database: ```javascript use config db.settings.updateOne({ _id: "chunksize" }, { $set: { value: 256 } }, { upsert: true }) ``` Since MongoDB 6.0 you can also scope it to one collection, which is far more useful in a mixed cluster where a huge append-only events collection and a small reference collection have completely different needs: ```javascript db.adminCommand({ configureCollectionBalancing: "app.events", chunkSize: 256 }) ``` Neither form rewrites existing ranges. The new value applies as ranges are split for future migrations, or merged by defragmentation. If you want existing metadata consolidated now, `configureCollectionBalancing` with `defragmentCollection: true` merges contiguous ranges owned by the same shard. ## The trade-off in both directions **Smaller ranges** mean more of them. Placement gets finer — the balancer can even out shards in small increments, and each individual migration copies less data, holds its critical section briefly and is easier to fit inside a maintenance window. The costs are volume and bookkeeping: more `config.chunks` documents, a larger routing table for every `mongos` and shard to cache and refresh, more balancer rounds, and more total overhead because each migration carries fixed costs (metadata commit, router refreshes, range-deletion scheduling) regardless of how little data it moves. **Larger ranges** mean fewer, heavier moves. Metadata stays small and the balancer is quieter, which is attractive on write-heavy clusters where migration traffic competes with the application for disk and cache. But each move copies more data, occupies its donor/recipient pair for longer, and blocks writes to that range for the duration of the commit critical section. Placement is coarser, so shards can sit further apart, and very large ranges are more likely to run into the indivisible-range problem where a single shard-key value cannot be split at all. ## When you would actually change it Most clusters never touch it, and "we tuned chunk size" is rarely the fix for a real problem. Reasons that hold up: - **Very large documents or very few distinct shard-key values**: a smaller range size can give the balancer something to work with, though a shard key with too little cardinality is a modelling problem, not a sizing one. - **Migration traffic hurting the workload**: raising the size reduces the number of moves, though scheduling with a balancer window is usually a better lever. - **A bulk load or backfill**: operators sometimes tune size alongside pre-splitting so the initial spread happens without a long migration tail. - **Metadata bloat**: a collection that accumulated an enormous number of tiny ranges over years is better served by defragmentation than by shrinking the size further. ## How to talk about it The honest framing is that range size trades *balance granularity* against *migration and metadata overhead*, and that the balance threshold is denominated in it. Anyone who claims a single "correct" value, or that shrinking the range size improves query performance, is guessing: routing cost depends on whether the query targets one shard, not on how many ranges exist.