Vertical Scaling Example: A Bigger Database Machine

Scaling up a database means moving it to a machine with more processors and memory, and changing nothing else. This example follows one PostgreSQL database on Amazon RDS, the managed database service on AWS, from one machine size to the next, and shows what the move buys and where the path ends.

The situation. A shop's database runs on a db.r6g.2xlarge machine. Its processors sit near 80% busy at the evening peak, and query times climb when they pass 90%. The team is two engineers.

What it buys. Twice the processors bring the peak from about 80% to about 40% busy, assuming the load is spread across processors, which is typical for many concurrent queries. Twice the memory keeps more of the data in memory, so fewer reads touch the disk. The application does not change at all: the change is a setting, applied in a maintenance window, often a few minutes of downtime or a switch to a standby copy.

Where it stops. The family has a largest size, and the shop is three doubling steps from it. If load doubles every year, the path runs out in about three years. Each step also doubles the cost, so the bill grows as fast as the machine.

What it does not fix. A bigger machine is still one machine. If it fails, the database is down until a standby takes over. Scaling up adds capacity, not spares.

So scale a database up while the next size exists and the team is small: it buys capacity with a setting, and the ceiling is in the price list where you can see it coming.