Vertical Scaling

What Vertical Scaling Is

Vertical scaling (also called scaling up) means making your one database server more powerful: more CPU, more RAM, faster disks. The app doesn't change. It still talks to one database, which is now bigger.

Think of a restaurant kitchen that can't keep up with orders. Vertical scaling is replacing the stove with a bigger one and hiring a faster chef, in the same kitchen. Horizontal scaling (later pages) is opening more kitchens.

1Before                          After (scale up)
2App → [ DB: 4 CPU, 16 GB RAM ]   App → [ DB: 32 CPU, 256 GB RAM, faster SSD ]
3       one server                       still one server, just bigger

What Each Upgrade Fixes

Upgrade	Helps when	Food app example
More RAM	Data and indexes don't fit in memory, so the DB keeps reading from disk	The `orders` indexes outgrew memory and "My Orders" slowed down
More CPU	Many queries run at once, or queries do heavy work (sorting, JOINs)	Dinner rush with thousands of queries per second
Faster disk (SSD/NVMe)	Lots of writes, or data too big for RAM	Every new order writes to the table, indexes, and WAL

RAM usually matters most. The data your app reads often is called the working set. When the working set fits in memory, most reads never touch the disk.

1Read from RAM   → well under a millisecond
2Read from SSD   → around 0.1 ms or more per read, and many reads add up
3Working set = 40 GB
4  16 GB server  → most reads hit disk → slow
5  64 GB server  → working set fits in memory → fast

You can check whether reads are coming from memory:

-- cache hit ratio: share of reads served from memory
SELECT round(sum(blks_hit) * 100.0 / nullif(sum(blks_hit) + sum(blks_read), 0), 2)
     AS cache_hit_percent
FROM pg_stat_database;
-- around 99% is healthy for a busy app; much lower suggests more RAM would help

Why Start Here

Vertical scaling is usually the first thing to try:

No code changes. Same connection string, same queries.
Everything still works. Transactions, JOINs, and constraints all run on one server, so nothing gets harder.
Simple to run. One server to back up, monitor, and debug.

Modern cloud servers are huge, with hundreds of CPU cores and terabytes of RAM available. Many apps run on one well-sized PostgreSQL server for years.

The Limits

Limit	What it means
Hard ceiling	There is a biggest machine. Once you outgrow it, scaling up stops working.
Cost grows fast	The largest machines cost much more per unit of power than mid-sized ones.
Single point of failure	One server. If it crashes, the whole app is down.
Downtime to upgrade	Moving to a bigger machine usually needs a restart or failover.

The single point of failure is often the bigger problem than the ceiling. Even a small app needs a backup server ready to take over.

Vertical vs Horizontal

	Vertical (scale up)	Horizontal (scale out)
How	Bigger server	More servers
Code changes	None	Often some (routing, shard keys, read replicas)
Transactions and JOINs	Simple, one server	Harder across servers
Limit	Biggest machine available	Very high
Failure	One server = full outage	Others can keep running
Choose when	Early stage, or load still fits one machine	Load outgrows one machine, or you need high availability

Interview Angle

How to Explain it in an Interview

The 30-Second Spoken Pitch

"Vertical scaling means giving the database server more CPU, RAM, or faster disks. It's usually my first step, because the app doesn't change and transactions and JOINs keep working on a single machine. RAM matters most: if the working set of data and indexes fits in memory, most reads avoid the disk. The downsides are a hard ceiling, costs that rise steeply at the top end, and a single point of failure. So even before I need more capacity, I add a replica for failover, and when one machine isn't enough, I move to horizontal scaling."

Common mistakes:

Jumping straight to sharding when a bigger server and better indexes would solve the problem.
Forgetting that one server, however big, is still a single point of failure.

Summary

1Vertical scaling → bigger server: more CPU, RAM, faster disk
2Biggest win      → working set fits in RAM
3Pros             → no code changes, transactions + JOINs stay simple
4Cons             → hard ceiling, high cost at the top, single point of failure
5Rule             → scale up first, scale out when one machine isn't enough

The single point of failure is the first limit most apps hit. Next, replication adds copies of the database on other servers for failover and extra read capacity.

Next TopicReplication and Replication Lag