CONCEPT Cited by 1 source
Highly composite shard count¶
Highly composite shard count is the practice of picking a total logical shard count that's divisible by a lot of smaller numbers (e.g. 60 / 120 / 360 — the highly-composite family) so the operator can scale out the physical-host fleet incrementally while preserving even shard-per-host distribution. Canonical framing from Justin Gage (Source: sources/2026-04-21-planetscale-what-is-database-sharding-and-how-does-it-work):
"This is why companies like to choose a number of shards that's divisible by a lot of smaller numbers; it allows you to scale out the number of servers incrementally while maintaining that smooth, even distribution."
Problem it solves¶
Shard counts are logical; host counts are physical. The two are related by shards_per_host = logical_shards / physical_hosts. When the logical shard count is small or prime (e.g. 7 shards), the only host counts that divide it evenly are {1, 7} — so scaling from 1 host to 2 hosts pins 4 shards on one and 3 on the other, permanently unbalanced until you reshard the logical layer.
A highly composite shard count (e.g. N=360) lets the operator add hosts at many intermediate points: 1 → 2 → 3 → 4 → 5 → 6 → 8 → 9 → 10 → 12 → 15 → 18 → 20 → 24 → ... → 360 all give every host exactly N/H shards. The rebalance work is bounded to moving (H-1)/H fraction of shards to new hosts each time, without touching the logical partitioning.
Why it isn't "just pick a power of 2"¶
Powers of 2 only give the operator doubling-scale-out options: 2 → 4 → 8 → 16 → .... Highly composite numbers offer finer-grained scale-out at comparable size. 60 = 2² × 3 × 5 has divisors {1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30, 60} — 12 options vs a power-of-2's log₂ options — letting the team scale by 50% or 25% increments when capacity demands, rather than being forced to double.
The Vitess convention of shard-range names (-40 / 40-80 / 80-c0 / c0- for 4 shards, -20 / 20-40 / 40-60 / 60-80 / 80-a0 / a0-c0 / c0-e0 / e0- for 8) composes cleanly with this — the logical ring is split at hex boundaries and the operator assigns ranges to hosts.
Connection to resharding¶
Once the operator needs to add logical shards (not just hosts), the Reshard-online-via-VReplication primitive copies data from the existing ranges into new ranges. Highly composite shard counts defer this moment by maximising how many physical-host-count levels can be absorbed purely by host-count changes. The further each logical-reshard is pushed back, the lower the lifetime cost of the sharding strategy.
Trade-off: over-sharding up-front¶
- Pro: maximum flexibility for horizontal scale-out without logical-layer changes.
- Pro: even shard-per-host distribution at many host counts.
- Con: small-shard fixed per-shard overhead (connection pool / buffer pool / replication stream per shard). Too many logical shards means each shard holds too little data to amortize per-shard fixed costs.
- Con: monitoring / admin tooling surface grows linearly with shard count.
The practical middle is the small-shards-wide-fleet discipline — pick the shard count so each shard's working set fits comfortably in memory/IOPS of a modest host, and the shard count is a highly composite number that absorbs several years of projected growth.
Seen in¶
- sources/2026-04-21-planetscale-what-is-database-sharding-and-how-does-it-work — Justin Gage (guest post for PlanetScale, 2023-04-06) canonicalises the "divisible by a lot of smaller numbers" heuristic in the context of initial-shard-count selection under flexibility-maximisation, framed as common industry practice rather than a proprietary trick. No specific numbers quoted; the generalisation from the framing is the load-bearing contribution.