Vertical scaling
VER-tih-kul SKAY-ling
Upgrading an existing server with more CPU, RAM, or storage instead of adding more servers.
Vertical scaling means making a single server bigger. More CPU. More RAM. More storage. Faster network. If your database server is running out of memory at 64GB, you upgrade to 128GB. Simple. No architecture changes. No distributed systems complexity. The same application runs on a more powerful machine.
Vertical scaling is underrated. The industry defaults to "just add more servers," but a single modern server can handle an enormous amount of work. A well-optimized PostgreSQL instance on a machine with 256GB RAM and 64 cores can handle millions of queries per day. Many companies run their entire workload on one or two servers for years before needing horizontal scaling.
The limit of vertical scaling is physics and cost. The biggest cloud instance available might have 448 CPUs and 24TB of RAM (AWS u-24tb1.metal), but it costs over $200 per hour. At some point, two medium servers are cheaper and more resilient than one massive server. Vertical scaling also provides no redundancy: if that one server dies, everything is down. Most mature architectures combine both: scale vertically until it stops being cost-effective, then scale horizontally.
Examples
A startup upgrades their database server.
The PostgreSQL database runs on an AWS db.r6g.xlarge (4 vCPUs, 32GB RAM). Query latency is climbing as the dataset grows. The team upgrades to db.r6g.4xlarge (16 vCPUs, 128GB RAM). Latency drops by 60%. The upgrade takes 15 minutes of downtime. No code changes. No schema changes. Total cost increase: $400/month.
A team hits the ceiling of vertical scaling.
The analytics database is on the largest available instance: 96 vCPUs and 768GB RAM. Queries still timeout during peak hours. There is no bigger machine to upgrade to. The team must now redesign: shard the database, move to a distributed query engine like ClickHouse, or offload analytics to a data warehouse like BigQuery.
An engineer argues for vertical over horizontal scaling.
A proposal calls for splitting the monolith into 8 microservices to handle growth. An engineer points out that the current server uses only 30% of available CPU. Upgrading to a 2x bigger instance costs $200/month. The microservices migration would take 3 months of engineering time. The team upgrades the server and revisits the architecture in six months.
In practice
Read more on the blog
Frequently asked questions
Is vertical scaling a bad practice?
No. Vertical scaling is the simplest way to handle growth and should be your first option. The industry over-indexes on horizontal scaling and distributed systems. A bigger server is cheaper, faster to implement, and introduces zero architectural complexity. Only move to horizontal scaling when vertical scaling becomes cost-prohibitive or when you need redundancy that a single server cannot provide.
How do you vertically scale without downtime?
Most cloud providers support instance resizing with minimal downtime. AWS RDS can resize a database instance with a few minutes of downtime during a maintenance window. For zero-downtime upgrades, use a replica: spin up a larger replica, let it sync, then promote it to primary. The old server becomes the new replica or gets terminated.
Related terms
Adding more servers to handle increased load, instead of upgrading existing servers.
Distributing incoming network traffic across multiple servers so no single server becomes a bottleneck.
Storing a copy of data in a faster location so repeated requests do not hit the slower original source.
The percentage of time a system is operational and accessible to users.
Content delivery network: a global network of servers that caches and serves content from locations close to users.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.