What is Scalability Testing?

What is scalability testing?

Scalability testing measures how a system's performance changes as you add resources — more pods, more nodes, bigger instances, more database replicas. The goal is to validate that adding 2× the infrastructure yields close to 2× the throughput (linear scaling), not 1.2× (sub-linear, expensive scaling) or 0.5× (negative scaling from coordination overhead).

Scalability testing vs load testing

A load test measures performance at a fixed infrastructure size. Scalability testing measures performance across multiple infrastructure sizes:

• Load test at 1,000 RPS on 1 node → p95 latency 600 ms.
• Scalability test across 1, 2, 4, 8 nodes → does 8 nodes handle 8,000 RPS at 600 ms (linear), 6,000 RPS at 600 ms (sub-linear), or 4,000 RPS at 1,200 ms (coordination overhead dominates)?

The scalability test isn't one run. It's a series of load tests at increasing capacity, with the data plotted to show the scaling curve.

Horizontal vs vertical scalability

• Horizontal scalability: add more nodes / pods / containers. Test by running the same load against 1, 2, 4, 8, 16 instances.
• Vertical scalability: increase one node's resources (CPU, memory, disk IOPS). Test by running the same load against small, medium, large, xlarge instances.

Most modern systems should scale horizontally cleanly. Stateful systems (databases especially) often scale vertically until they hit hardware limits, then need sharding or read-replicas for further scale.

When to run scalability tests

• Before committing infrastructure budget. If you need 10,000 RPS and each node handles 1,000, do you need 10 nodes or 15? Scalability testing tells you the real ratio.
• Validating autoscaling. Autoscaling assumes adding pods adds proportional capacity. Scalability testing confirms (or finds the coordination overhead that breaks the assumption).
• Pre-architecture-change. Migrating from monolith to microservices? The new architecture's scaling characteristics are unknown until tested.
• Database scaling validation. Adding read replicas, sharding, or going to a managed scaling service? Validate the new topology scales as advertised.
• Vendor evaluation. Comparing Aurora vs RDS vs DynamoDB? Run the same workload against each at increasing scale and compare.

Key scalability-test metrics

1. Scaling factor. Throughput at 2N nodes / throughput at N nodes. Should be ~2.0 for linear scaling.
2. Per-node throughput. Throughput at scale divided by node count. Should stay constant; if it drops, you're hitting coordination overhead.
3. Per-node latency. Latency at scale vs latency at single-node. Should stay constant or improve; if it climbs, coordination is expensive.
4. Coordination overhead breakdown. Where is time going as scale grows? Cross-node network calls? Distributed locks? Consensus protocols? Identifying the overhead source tells you what to fix.

How to run a scalability test

The mechanics: run the same load test against the system at multiple infrastructure sizes. Plot throughput, per-node throughput, and p95 latency across the sizes.

In JMeter or k6, the script stays identical between runs. Change only the infrastructure (scale the deployment, change instance class, add read replicas). The load test then measures the resulting performance.

Run from LoadFocus for consistent load generation across the test series — using the same regions and the same VU count ensures the only variable is your infrastructure, not the test harness.

For scalability tests that inform multi-year infrastructure planning, LoadFocus offers load testing services where engineers design the scale points, run the test series, and produce the scaling-curve analysis with cost-per-RPS implications.