Skip to content

CONCEPT Cited by 1 source

Vertical-scaling cost step-function

The cost of vertical scaling a database is a step-function, not a smooth curve: each hardware tier-upgrade is a discrete jump that forces the operator to pay for unused headroom to buy a capacity runway, because the next-tier machine is substantially larger than the tier it replaces and rarely sized to the workload's actual present need.

Canonical framing

Lucy Burns + Taylor Barnett, PlanetScale, 2023-08-31 (Source: sources/2026-04-21-planetscale-horizontal-sharding-for-mysql-made-easy): "It's inefficient to make big leaps in hardware to overprovision for potential spikes in traffic or use. With this method, you will end up paying for resources that you don't have an immediate need for just to prepare for anticipated spikes in traffic. Once you outgrow your current machine, the next you invest in could easily be 50% larger, while you really only end up using 10% of it."

The post's explicit graph: a step-function that illustrates the unpredictable and often substantial cost associated with vertical scaling, contrasted with a linear increasing line for horizontal sharding — incremental and predictable cost as data volume grows.

Worked example

  • Tier N: 64 vCPU / 256 GB RAM machine, ~85% utilised. Time to upgrade.
  • Tier N+1: 96 vCPU / 384 GB RAM — the smallest next-tier offering. 50% more capacity, 50% more cost.
  • Actual near-term usage: the workload genuinely needs ~10–15% more capacity than Tier N, not 50% more.
  • Paid-but-unused ratio: ~4–5× — i.e. 40% of Tier N+1's capacity sits as paid headroom that won't be consumed for months or years, purely to buy the runway to the next upgrade.

Burns / Barnett state this as: "the next you invest in could easily be 50% larger, while you really only end up using 10% of it." The paid-but-unused ratio at tier-boundary-crossing is often >4×.

Why horizontal sharding escapes this

The unit of capacity addition is small relative to the total fleet. Adding one shard to an N-shard cluster buys 1/N of additional capacity — not a doubling. Burns/Barnett: "This level of granularity enables you to add smaller hosts and invest in your infrastructure more efficiently." The cost curve becomes linear (each shard's cost is predictable; total cost grows with data volume) rather than stepped (each next-tier machine is 50% more expensive, consumed at 10%).

See also concepts/linear-vs-superlinear-cost-scaling for the broader framing: when scaling units are small and independent, total system cost can grow linearly with load. When they aren't — when the only lever is a discrete hardware upgrade — cost is forced up in discrete steps that decouple from actual demand.

Operational implications

  • Capacity planning becomes a bet on future headroom, not a budget for present load. The operator who upgrades to Tier N+1 at 85% Tier-N utilisation is paying 4× the true marginal-capacity cost to get N+1 → Tier N+1's 85% point, which might be 18 months out.
  • The 10% → 85% fill-curve is the budget risk. If workload growth slows, the operator paid for a tier they won't fill for a decade. If growth accelerates, they face the next step in six months — compounding the over-provisioning.
  • Cloud provider tier design amplifies the step. RDS, Aurora, and GCE tiers aren't sized for 10% capacity increments — they're sized for 2× jumps at well-known price points. The substrate itself enforces the step-function.
  • At the top of the ladder, there is no next step. Vertical scaling hits a ceiling — the largest available instance class — at which point the step-function ends and there is no tier above to jump to. This is precisely when horizontal sharding becomes mandatory rather than merely economically preferable (see concepts/scaling-ladder).

Distinction from generic vertical-scaling cost

Vertical scaling as a concept is about the lever (increase single-machine capacity). The step-function-cost framing is specifically about why the economics of that lever degrade non-linearly: the cost of the lever itself increases in discrete jumps that don't align with smooth demand growth. A team might be happy vertically scaling from Tier 4 → Tier 5 if the machine is 10% more expensive and 10% more capable. In practice the cloud-provider menu is Tier 4 → Tier 5 at 50% more capacity / 50% more cost, and the workload sits unevenly at 50–85% of Tier 4 → 33–57% of Tier 5 until growth catches up. The discrete-tier-menu is the mechanism of the cost discontinuity.

Seen in

  • sources/2026-04-21-planetscale-horizontal-sharding-for-mysql-made-easy — Burns + Barnett canonicalise the step-function framing with the 50%-larger / 10%-used worked example and the explicit step-function-vs-linear-line graph. The framing is used as the economic argument for horizontal sharding, parallel to the operational argument (feature-set shrinks / scatter-gather / resharding complexity). Connects to the scaling ladder: each rung (vertical scaling → vertical sharding → horizontal sharding) has a different cost curve shape, and the operator's calculus is not just "when do I run out of capacity" but "when does the shape of my cost curve start penalising me more than the operational complexity of the next rung penalises me."
Last updated · 550 distilled / 1,221 read