Vertical Scaling
Vertical scaling (scale up) means making a single machine bigger — more CPU, more RAM, faster disks — instead of adding more machines. It is the simplest scaling strategy: no code changes, no distributed systems, no statelessness required. The trade-off is a hard ceiling (the biggest available instance), downtime to upgrade, and a single point of failure. Vertical scaling is the right first step for most systems; horizontal scaling becomes necessary when you hit the vertical ceiling or need fault tolerance.
Foundational.
How it works
Vertical scaling (scale up) means making your single machine bigger — more CPU cores, more RAM, faster disks, more network bandwidth — without adding more machines. The application code is unchanged; you just give it more resources.
Contrast this with horizontal scaling (scale out), which means adding more machines and distributing load across them. Horizontal scaling requires statelessness, distributed data, load balancing, and failure handling. Vertical scaling requires none of these — the system architecture is unchanged.
This makes vertical scaling the right first move for most systems. A database that is slow on a 4-core / 16 GB instance will likely be fast on a 32-core / 128 GB instance, with no code changes and no sharding required. The relational database industry is built on this observation: a single beefy PostgreSQL instance can handle enormous load on a single machine, and only the largest workloads ever need to shard.
The cost is two-fold: (a) there is a hard ceiling — the biggest machine AWS offers is u-6tb1.metal (6 TB RAM, ~$10k/month) — and beyond that you must scale horizontally; (b) a single machine is a single point of failure unless you pair it with a synchronous replica.
When vertical scaling is the right answer:
-
You are below the ceiling. If a 64-core / 256 GB machine handles your load, vertical scaling is correct. The biggest AWS instances are 100x that size; you have headroom.
-
Your workload is I/O-bound. A single machine with NVMe disks and lots of RAM often outperforms a sharded cluster. Network calls between shards are slow (1-5 ms); in-process memory access is microseconds. For databases especially, sharding is rarely worth the complexity until you absolutely need it.
-
Your system is stateful and hard to shard. Relational databases with complex transactions, joins across tables, and foreign-key constraints are very hard to shard correctly. Vertical scaling delays the sharding decision by years for most applications.
-
You are early-stage or small. A startup with 10,000 users does not need a sharded cluster of microservices. A single big machine is simpler, cheaper, and more reliable.
-
Operational simplicity matters. A single machine is easier to operate, monitor, debug, and back up than a distributed cluster. If your team is small, vertical scaling preserves operational capacity.
When horizontal scaling becomes necessary:
-
You are approaching the vertical ceiling. If you need 8 TB of RAM and the biggest instance is 6 TB, you must shard.
-
You need fault tolerance. A single machine, even with a replica, has a higher failure correlation than independent machines in different racks/AZs.
-
You need geographic distribution. A single machine in one region cannot serve users in another region with low latency. You need multiple machines in multiple regions (and they will be horizontally scaled within each region).
-
Your workload is embarrassingly parallel. Web/app servers are stateless and trivially horizontal — scaling them vertically is usually more expensive than scaling horizontally.
-
Cost. Above a certain size, N small machines are cheaper than 1 big machine, because big machines carry a price premium per unit of compute.
The single most important rule of database scaling: scale vertically until you cannot, then shard. Sharding a relational database is one of the hardest engineering problems — cross-shard transactions, joins, schema migrations, and rebalancing all become exponentially harder. Most production databases never need to shard; a single big instance with read replicas handles the load. The companies that did shard (Uber, Facebook, Google) did so only after exhausting vertical options, and they speak openly about how painful it was. Do not shard prematurely.
The ceiling and the cost premium.
Vertical scaling hits two hard limits: the biggest machine available, and the price-per-unit of compute on big machines.
The biggest machines (as of 2025):
- AWS:
u-7tb1.metal— 7 TB RAM, 448 vCPUs, ~$100k/month. - Azure: M-series — up to 4 TB RAM, similar pricing.
- GCP:
m3-ultramem-128— 4 TB RAM, similar. - On-prem: limited only by hardware availability and budget; the largest x86 servers have 8-12 TB RAM.
Beyond these, vertical scaling is impossible — you must shard. In practice, very few workloads need a single machine larger than 1 TB of RAM. Most applications are well-served by a 64-256 GB instance, which is widely available and affordable.
The price premium. Big machines cost more per unit of compute than small ones. A u-7tb1.metal instance is ~$100k/month for 448 vCPUs and 7 TB RAM. The same 448 vCPUs and 7 TB RAM distributed across 56 m5.2xlarge instances (8 vCPU / 32 GB each) costs ~$15k/month. The big machine costs 7x more per unit. This is the price of not having to shard — and it is often worth it for the operational simplicity, but it is a real cost.
The deeper lesson: vertical scaling is paid in dollars; horizontal scaling is paid in engineering complexity. At some scale, the engineering cost of horizontal exceeds the dollar cost of vertical — but only at extreme scale. Below that scale, vertical is the right answer.
The single point of failure problem.
A vertically scaled system has, by definition, one machine handling the load. If that machine fails, the system is down — unless you have a synchronous replica.
The standard pattern for stateful vertical systems (databases especially):
- Primary + synchronous replica. Writes go to the primary; the primary forwards WAL/binlog to the replica synchronously. If the primary dies, the replica is promoted. RPO ≈ 0 (no committed data loss), RTO ≈ seconds to minutes (failover time).
- Primary + asynchronous replica. Writes go to the primary; replication is asynchronous. If the primary dies, you may lose the last few seconds of writes (RPO > 0), but the replica is available.
- Multi-AZ deployment. Primary in one AZ, synchronous replica in another. Survives AZ failure.
- Multi-region. Primary in one region, async replica in another. Survives region failure (with RPO > 0).
The key insight is that vertical scaling is compatible with high availability — but only by adding replicas. A single machine cannot be highly available; it can only be made tolerant by having a hot standby. This is fundamentally different from horizontal scaling, where the loss of one of N nodes is a graceful degradation, not a failover event.
This is why the question "vertical or horizontal?" is the wrong question. The right question is: "vertical with HA replicas, or horizontal with N nodes?" Both can be highly available; the choice depends on workload characteristics (stateful workloads favor vertical with replicas), the vertical ceiling (have you hit it?), and engineering capacity (can you operate a sharded system?).
Your startup's PostgreSQL database is slow at 100 GB. The team proposes sharding across 4 instances. What is the right response?
Pick one answer.
You are choosing between one `u-7tb1.metal` instance (~$100k/month, 448 vCPU, 7 TB RAM) and 56 `m5.2xlarge` instances (~$15k/month total, same aggregate vCPU and RAM). What factors beyond cost determine the choice?
Pick one answer.
You vertically scale your database by upgrading to an instance with 4x the RAM. Performance barely improves. What is the likely diagnosis?
Pick one answer.
Engineering mental model
Mental model. Think of Vertical Scaling as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does Vertical Scaling mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”
Before choosing Vertical Scaling, name the workload, the critical user path, the dominant bottleneck, the failure you are trying to absorb, and the trade-off you are willing to accept. If you cannot name those five things, the design is probably premature.
// Pseudocode
request = receive()
result = vertical_scaling(request)
return result
// Production questions:
// 1. What happens on timeout?
// 2. Can this operation be retried safely?
// 3. What is the bottleneck?Back-of-the-envelope reasoning
Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.
Interactive thought experiment: Vertical Scaling
Change the variables below and predict what breaks first in Vertical Scaling. The production lab can later reuse these same inputs.
Change one variable at a time. Predict the failure mode first, then move the slider and see whether your mental model matches the simplified system response.
If you are stuck on Vertical Scaling, start by drawing the request path and marking every network hop, stateful component, queue, cache and failure boundary. Then estimate where the system will saturate.
You increase traffic by 10× in a system using Vertical Scaling. What should you inspect first?
Pick one answer.
Which statement is the safest engineering habit when using Vertical Scaling?
Pick one answer.
You have dashboards for traffic, latency, errors and saturation. You can change the architecture, but every change has operational cost.
Production scenario: your system uses Vertical Scaling, traffic suddenly spikes, and p99 latency doubles. What is your first move?
Interview drill
Answer this without notes: When would you choose Vertical Scaling, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.
A useful engineering lens for Vertical Scaling: define the problem it solves, the simpler design that fails first, the constraint that forces you to introduce this concept, and the new failure modes the concept creates.
Numerical sanity check
Back-of-the-envelope reasoning beats fake precision. State your traffic, payload, concurrency and growth assumptions explicitly, then calculate enough to know whether the current architecture is orders of magnitude away from the target.
Do not optimize for a memorized definition. Reason from the workload and failure mode.
Imagine the simplest version of a system using Vertical Scaling. What breaks first as traffic grows by 10×, and what would you change before reaching 100×?
Pick one answer.
What you gain, what you pay
- +Simplest scaling strategy — no code changes, no distributed systems.
- +Often outperforms horizontal clusters for I/O-bound workloads (databases).
- +No statelessness, sharding, or coordination required.
- +Operationally simpler — one machine to monitor, debug, back up.
- +Right first move for most systems — defer horizontal complexity.
- −Hard ceiling — the biggest available machine.
- −Upgrade usually requires downtime (restart on bigger instance).
- −Single point of failure unless paired with a synchronous replica.
- −Price premium per unit of compute on big machines (3-7x small instances).
- −Does not address geographic distribution — single region only.
How this breaks in production
- Hitting the ceiling — workload exceeds the biggest available machine.
- Single point of failure — primary dies, no replica, system down.
- Cost cliff — vertical scaling beyond ~256 GB RAM becomes disproportionately expensive.
- Misdiagnosis — scaling RAM when CPU or query plan was the bottleneck.
- Upgrade downtime — resizing an instance requires a restart.
- Failure correlation — primary and replica in the same AZ/rack go down together.
Don't fall into these traps
- •Sharding prematurely — scaling horizontally when vertical would suffice.
- •Adding RAM without diagnosing the actual bottleneck — wasted spend, no improvement.
- •Single-instance deployment without a replica — guaranteed downtime on failure.
- •Primary and replica in the same AZ — correlated failures.
- •Treating vertical and horizontal as mutually exclusive — most systems use both (vertical for stateful, horizontal for stateless).
- •Forgetting that vertical scaling has a ceiling — designing as if you can always scale up.
Real systems using this
How real systems implement this
- PostgreSQL / MySQL primary databases at most companies — The default database deployment pattern: a single vertically scaled primary (64-256 GB RAM is common) with synchronous replicas for HA. Most production databases never need to shard — vertical scaling carries them for years.
- Stripe, GitHub (early stage) — Both companies ran on single large PostgreSQL instances for years before needing to shard. Stripe has spoken publicly about deferring the sharding decision; GitHub still runs a primary PostgreSQL that handles their main workload.
- AWS RDS / Aurora — AWS's managed database offerings are vertically scaled by design — you pick an instance size, and AWS manages the machine. Read replicas provide read scaling; multi-AZ provides HA. Vertical scaling is the explicit design.
- Single-tenant SaaS (e.g., enterprise GitLab dedicated) — Single-tenant enterprise deployments often run each customer on a dedicated big instance — vertical scaling per customer, with no multi-tenant complexity. Cost per customer is high; isolation is complete.
Practice saying it out loud
- Q1When would you choose vertical over horizontal scaling? When does horizontal become necessary?
- Q2Your startup's PostgreSQL is slow at 100 GB. The team proposes sharding across 4 instances. What do you say?
- Q3A single big instance costs 7x what an equivalent cluster of small instances costs. When is it worth it?
- Q4How do you make a vertically scaled database highly available?
- Q5You vertically scaled by adding RAM, but performance did not improve. Diagnose.
Further reading & references
Core explanations are original NO CAP material. External references are provided for deeper study and standards.
What next?
Mark as understood once the mental model clicks.
Next recommended
Horizontal Scaling