Skip to content

CONCEPT Cited by 2 sources

Vertical scaling

Vertical scaling is the discipline of increasing a single server's capacity — more CPU cores, more RAM, faster storage, higher IOPS — rather than distributing load across multiple servers. It is the first rung of the database scaling ladder: cheap, transparent to the application (no SQL or connection-string changes), incrementally applied.

Why reach for it first

  • Zero application impact. No SQL changes, no routing logic, no shard-key decisions. Everything the app did yesterday still works today.
  • Operational simplicity. One instance to back up, monitor, upgrade. All the complexity of horizontal sharding — cross-shard queries, shard-key selection, proxy tier, per-shard replica sets — is still in the future.
  • Substrate-dependent cost. On bare metal, vertical scaling means installing disks and migrating data. On cloud VMs (EC2, GCE), it's a volume snapshot → resize → partition expansion sequence, often online (Source: sources/2026-04-21-planetscale-dealing-with-large-tables). On managed services (PlanetScale, RDS), storage auto-grows.

The ceiling

Vertical scaling stops being viable when:

  1. Economic cost becomes prohibitive. "Physical machines and cloud VMs can become prohibitively expensive as you start to reach machines that have hundreds of gigabytes of RAM and many CPU cores" (Source: sources/2026-04-21-planetscale-dealing-with-large-tables).
  2. Memory contention dominates. Even with a large machine, lock contention, cache-coherence overhead, and NUMA effects degrade per-core performance.
  3. IOPS ceiling on network-attached storage. RDS / CloudSQL / EBS cap out at provisioned IOPS. Cloud substrates that separate storage from compute hit this wall earlier than direct-attached NVMe.
  4. Working set no longer fits in RAM. Cold reads hit disk; query latency degrades.

Substrate dependence

The vertical-scaling ceiling is not a fixed number. It depends on the substrate:

  • Network-attached storage (AWS RDS, Google CloudSQL) — hits the IOPS / IO-latency ceiling earlier because every IO crosses a network hop.
  • Direct-attached NVMe (PlanetScale Metal) — storage and compute live on the same hardware. "This reduces network hops and provides better hardware, delivering substantially higher IOPS. If you're on Metal, you can often delay sharding and continue scaling vertically much further (into the several TB range) than traditional cloud database architectures allow." (Source: sources/2026-04-21-planetscale-guide-to-scaling-your-database-when-to-shard-mysql-and-postgres).

The practical implication: the "when to shard" decision is substrate-conditioned. On EBS-backed RDS the ceiling arrives sooner; on Metal it arrives later.

  • Vertical scaling vs vertical partitioning: vertical scaling makes one instance bigger; vertical partitioning moves table groups onto separate instances. Orthogonal levers.
  • Vertical scaling vs horizontal sharding: vertical scaling keeps all rows on one host; horizontal sharding splits rows across hosts by shard key.
  • Vertical scaling on the scaling ladder: always the first rung. Skip to sharding only when a specific trigger signal fires (data size → working set overflow, write throughput → IOPS saturation, read throughput → replication-lag-bound staleness).

Seen in

Last updated · 347 distilled / 1,201 read