Vertical Database Scaling

The First Rung, Always

 database struggling? BEFORE any architecture change:

 db.r6g.4xlarge  (16 vCPU, 128GB)  →  db.r6g.16xlarge (64 vCPU, 512GB)

 one console click. zero code change. zero migration risk.
 buys months of headroom while you do REAL capacity math.

 this is the correct FIRST response almost every time —
 sharding a database that needed 2x RAM is a classic
 over-engineering wound.

What Vertical Buys in a Database Specifically

Resource	Effect
RAM ↑	Bigger buffer pool → working set cached → disk idle
CPU ↑	More concurrent queries, faster sorts/hashes
IOPS/NIC ↑	Write throughput ceiling rises
NVMe local	Random reads at memory-adjacent speeds

 the RAM row is the highest-leverage:
 performance cliffs vanish when the hot working set
 fits in the buffer pool. compute your working set
 (hot rows × width × indexes × safety) and size to it.

The Ceilings, Quantified

 PHYSICAL:   largest managed instance ≈ hundreds of vCPU,
             ~TBs of RAM. beyond that: exotic hardware.
 ECONOMIC:   price-per-core RISES steeply with size;
             top tier costs multiples of mid-tier per unit work.
 FAILURE:    single node = full blast radius; failover = restart
             window even WITH a standby (cache loss, connection drain).
 WRITE CEILING: even monster boxes cap on write IOPS + WAL
             throughput. writes don't parallelize within one node.

The Standard Topology While Vertical

 [primary: big] ══async/sync replication══► [standby: same size]

 - failover automated by managed services (RDS/Aurora/Cloud SQL)
 - planned maintenance = switchover to standby, upgrade, back
 - read scaling comes from ADDITIONAL replicas (next lesson),
   not from vertical alone

 vertical + standby is THE default production posture
 until measured forces break it.

Signals You’ve Outgrown Vertical

 □ next instance tier doubles COST, not headroom
 □ WAL/disk-write throughput saturated (writes can't scale up)
 □ backup windows unacceptable (hours to snapshot TBs)
 □ buffer pool still thrashing at max RAM (working set > possible)
 □ failover duration violates availability SLOs
 
 any two of these → start the replicas/sharding conversation
 WHILE there's runway, not during an incident.

Interview Framing

“Postgres at 90% CPU” scored opening: quantify the vertical move (“next tier is 4x — takes us from 50k to ~180k queries/sec equivalent”), note it’s zero-risk and immediate, THEN ladder onward conditionally (“read-heavy? replicas next. write-bound? caching then sharding”). Candidates who shard first skip three cheaper rungs and lose the room.