Autoscaling
is not
scalability.

The original essay, with interactive illustrations. All models use hypothetical numbers.

“you can tell how inexperienced an engineer is by the degree in which they believe in autoscaling.”

Sam Lambert · X · August 15, 2026 · quoted in the original essay

I saw this post making the rounds on X in the middle of my two-week vacation in Europe and, naturally, prioritizing relaxation during my time off, decided to spend a whole bunch of time thinking and writing about it.

It’s designed to have that effect, in a way. The post succinctly makes a judgement about one’s experience with enough vagueness around autoscaling to encourage engagement.

So here I am engaging with it.

A SWE or SRE will read the original post and reasonably say:

“I’m encouraged to have autoscaling enabled. Why is that bad?”

And it isn’t, of course. Autoscaling is useful, but it’s not a panacea.

It’s also a great bit of marketing by Sam Lambert, the CEO of PlanetScale, a company whose product is specifically designed to absorb a lot of the difficult operational work involved in running and scaling databases.

Everyone who reads “believe in autoscaling” is going to bring their own definition of both “believe” and “autoscaling” to it, and that ambiguity is useful. The disagreement it creates exposes how much we tend to pack into the word autoscaling, and how easily we let it stand in for scalability more broadly.

Sam’s follow-up suggests that was at least part of the point: the simple experience of “it just autoscaled” can sit on top of a whole lot of engineering complexity, while still describing only one part of what makes a system actually scale.

A follow-up post by Sam helped to clarify:

A customer described a PlanetScale database that “literally just autoscaled.” Lambert’s response: “so proud of this. it means we got the complex bit right.”

Sam Lambert · X · August 16, 2026 · exchange quoted in the original essay

The PlanetScale customer isn’t wrong. From their perspective, traffic increased, the database continued to work, and PlanetScale handled the capacity change. It really did “just autoscale.”

And Sam isn’t wrong either, making that sentence true is the product.

A common mistake is in an assumption that can come next: “My service autoscales, therefore my system is scalable”.

It’s usually not that explicit. More often: autoscaling is enabled, the box is checked, and the capacity conversation ends before anyone has defined useful work, validated the scaling signal, or tested what happens at the ceiling.

Autoscaling is always scoped

A good infrastructure abstraction should allow its consumer to use a simpler mental model.

The consumer sees:

load increases
→ database autoscales
→ application continues working

The platform provider has to think about:

signals selection
→ scaling thresholds
→ minimum and maximum capacity
→ provisioning
→ placement
→ routing
→ replication
→ warmup
→ failover
→ recovery
→ cloud-provider constraints
→ cost

If every PlanetScale customer had to understand all of that before trusting the product, PlanetScale wouldn’t have successfully abstracted the problem. So ‘it literally just autoscaled’ is evidence that a complex implementation produced a simple experience, not that the problem was always simple.

The danger comes when we extend that experience beyond the boundary of the abstraction.

A PlanetScale database successfully autoscaling doesn’t mean that the application as a whole is scalable. It means PlanetScale successfully handled a changing capacity requirement within the part of the system it owns. A good abstraction can hide the complexity of scaling a resource, but it can’t make the scope of that resource disappear.

Even inside PlanetScale, “autoscaling” doesn’t refer to one universal behavior. PlanetScale Vitess can automatically change the number of VTGate processes based on CPU utilization, within configured bounds. Network-attached storage can grow automatically. PlanetScale Postgres, meanwhile, doesn’t currently autoscale CPU and RAM; customers deliberately select and resize that compute themselves.

The dividing line is state. A VTGate is a stateless proxy, so adding capacity means starting another process. Adding database capacity generally means moving or replicating state: rebalancing data, catching up replication, warming caches. Network-attached storage can grow automatically because nothing has to move; the state expands in place. State is the reason “my database literally just autoscaled” was a remarkable sentence in the first place.

Autoscaling isn’t the same as scalability

I think what’s at the core of Sam’s original post is that autoscaling != scalability.

But why, exactly?

Oftentimes, scalability, elasticity, resilience, and efficiency all get collapsed into “scalability,” despite being separate properties that answer different questions.

Elasticity: Can the system add or remove capacity as demand changes?

Scalability: Does adding capacity actually produce more useful throughput?

Resilience: What happens before capacity arrives, when a dependency saturates, or after the scaling limit is reached?

Efficiency: How much does each unit of useful work cost?

Autoscaling primarily addresses elasticity. It can contribute to the other three, but it proves none of them.

On its own, an autoscaler is a delayed supply-side control loop with a relatively narrow job:

observe a signal
→ compare it with a target
→ change the amount of capacity
→ wait for the system to respond

The loop is simple, but the assumptions are not: that the signal actually represents demand or saturation, that capacity will arrive before the system exhausts its headroom, that the application can use the added capacity, that dependencies can absorb the additional work, and that scaling won’t make the current failure worse.

The metric is itself a capacity model

CPU, memory, request count, and queue depth are all observable metrics, but none is automatically the correct representation of load. Requests per second may work well when requests have reasonably similar costs, but it becomes less useful when one request consumes ten times as much CPU, memory, database time, or downstream capacity as another. Queue depth may look like an obvious scaling signal, but a queue of 10,000 one-millisecond jobs is a very different problem from a queue of 10,000 ten-second jobs.

Meta describes throughput autoscaling in terms of useful work: for a conventional web service, useful work might be requests per second; for an ML ranking service, the number of elements ranked per second, because the cost of individual requests varied too much for request count to describe the workload accurately.

That’s a more useful way to think about metric selection:

A scaling metric is a claim about what constitutes work and how much capacity that work requires.

And that’s one of the things a managed infrastructure provider generally can’t define for us. A database platform can observe CPU, query latency, connection usage, rows read, and I/O. It can’t automatically know that one query supports a critical checkout while another belongs to a background analytics job that could safely wait.

PlanetScale’s Database Traffic Control documentation draws this boundary explicitly: it can block queries that exceed a configured resource budget, but the application still has to handle that rejection through fallback behavior, circuit breakers, retry policy, or some other deliberate response.

The provider can supply the mechanism, but the application still has to define what the work means.

Capacity is a property of the request path

An autoscaler also has a fundamental limitation: it can usually change only the resource it controls.

Your application autoscaler may be able to add pods. It probably can’t also increase the write throughput of your database, a third-party API quota, the number of partitions in your queue, downstream connection limits, or the concurrency another service can safely absorb.

This leads to what I think is one of the most useful lessons in the whole discussion:

Capacity is a property of the request path, not of an individual deployment.

The end-to-end capacity of a request is constrained by the tightest point in a larger dependency graph. Scaling one component may move that bottleneck. It may expose a new one. In some cases, it allows the component to reach the existing bottleneck faster.

OpenAI’s PostgreSQL engineering write-up from earlier this year provides a great real-world example.

ChatGPT runs on a single primary writer with roughly fifty read replicas. Every replica added increases read capacity, and it also gives the primary one more instance to stream write-ahead log data to. As the replica count grows, that fan-out puts increasing network and CPU pressure on the one component that can’t be replicated away, which is why OpenAI is building cascading replication before it becomes the binding constraint.

And replicas were never the whole strategy. The same write-up covers query optimization, isolation of high- and low-priority workloads, connection pooling, protection from cache-miss storms, rate limiting at multiple layers, sharding of write-heavy workloads, and constrained retries that could otherwise amplify an overload event. The database was an important part of the capacity model, but it was only one piece of the puzzle.

The same is true of any component we buy rather than build. It may solve its own layer extremely well, but it doesn’t control the application tier, every upstream producer, every downstream service, or the complete path a business transaction follows.

A component can successfully autoscale while the system around it becomes less stable.

Autoscaling is only one part of overload management

The limits become especially visible when the autoscaler can’t obtain additional capacity at all.

PlanetScale experienced exactly thisduring the October 2025 AWS us-east-1 incident. At one stage it couldn’t launch new EC2 instances, and customers using diurnal VTGate autoscaling were approaching the US workday with substantially less capacity than they would normally have had.

The response involved much more than waiting for autoscaling to recover: the team delayed backups that would have required additional instances, stopped terminating existing capacity, packed VTGate processes more tightly onto the machines already available, and advised customers to shed nonessential database load by delaying queue processing or pausing ETL workloads.

This is a particularly useful example because it comes from the same company whose customer said the database “literally just autoscaled.”

When the supply path worked, the customer received a wonderfully simple experience. When it was blocked, resilience came from an entire set of controls that didn’t add supply: available headroom, workload prioritization, bounded queues, delayed background processing, load shedding, tighter packing of existing resources, and isolation between control-plane and data-plane failures.

Autoscaling belongs inside this larger overload-management system.

Queues absorb temporary variance, but they don’t create throughput. Backpressure limits how quickly new work enters the system. Admission control and load shedding reject work before it consumes scarce resources. Graceful degradation makes accepted work cheaper. Retry control prevents failures from producing even more demand. Isolation stops one tenant, feature, or workload from consuming every shared resource.

The failure modes run in the other direction, too. Many real autoscaling incidents are scale-in mistakes: flapping between sizes, scaling in just before a burst, cooldowns tuned for a traffic pattern that no longer exists.

PlanetScale’s own capacity guidance recognizes the timing problem. For an anticipated launch or event, it recommends temporarily increasing cluster capacity ahead of the expected traffic rather than assuming reactive behavior will always arrive in time. Reactive scaling handles unexpected variance while pre-scaling handles expected demand.

Headroom and overload controls help by protecting the interval between demand arriving and capacity becoming useful while also protecting the system after its scaling limit has been reached.

Here is one burst handled three ways. Each policy decides what happens to work that can’t be served yet:

• Queue everything. Accept every request and serve them in order.
• Cap the queue. Accept requests until 2,000 are waiting, then reject new ones immediately.
• Drop late work. Accept every request, but skip any that has waited longer than its client will.

The burst, the five-second client timeout and the autoscaler’s 30-second delay are the same in all three.

The hidden failure signal of cost

When an autoscaler adds capacity, the bill follows automatically; that’s how usage-based pricing works, on every provider. The visibility is valuable, but it’s still a resource-level view of cost: it tells us how much capacity we consumed, not whether that capacity produced proportionally more valuable work across the entire application.

Consider a hypothetical release:

Before:
1,000 successful requests
10 application instances
healthy latency

After:
1,000 successful requests
20 application instances
healthy latency

A conventional availability dashboard remains green, latency remains healthy. The autoscaler did exactly what it was configured to do, but the software now requires twice as much compute to perform the same amount of useful work.

The autoscaler has quietly converted a performance regression into spend.

This is one of the ways elasticity can create false confidence in a rollout. The system remains available because the infrastructure absorbs the regression quickly enough that users don’t experience it as an outage.

That’s a good outcome for immediate availability, but it’s still an engineering regression. It has also quietly consumed headroom: the service now sits closer to its scaling and dependency limits, and the next burst will reach them sooner.

This is why requests, CPU, and memory shouldn’t be the end of the measurement model. We need to define what constitutes a useful unit of work for the service: a successful request, a completed job, a transaction, a ranked item, an inference.

We can then measure cost against it: CPU-seconds per successful request, database work per transaction, GPU-seconds per successful inference, or compute cost per thousand SLO-compliant requests.

The FinOps Foundation describes this as unit economics: connecting technology cost to a meaningful unit of work rather than evaluating total spend in isolation. Cost per useful unit should sit right beside latency and error rate.

Test beyond the autoscaler

This framing also changes what it means to test autoscaling. A test that proves the replica count increased has mostly demonstrated that the controller is connected. A more meaningful test strategy asks:

• Does the chosen metric move proportionally with useful work?
• How long does it take for new capacity to become useful?
• What happens during a sudden burst, and during a gradual ramp?
• Does a cold cache make new capacity temporarily harmful?
• Which dependency saturates next?
• Do retries amplify the overload?
• Does the system reject work cheaply, or let it wait until it’s useless?
• Can nonessential features degrade without affecting critical paths?
• How long do recovery and backlog drainage take?
• Does cost per useful unit change under load, or after a deployment?

Then cap scaling and keep testing. The most important behavior may be what happens after no more capacity can be added.

Google’s SRE guidance recommends testing not just until a service reaches its capacity limit, but through the resulting overload behavior and recovery. Its broader guidance treats queues, load shedding, graceful degradation, and retry control as complementary mechanisms rather than substitutes for capacity planning. Does the service reject excess work predictably while continuing to complete the most important work? Does it accumulate a queue it can never realistically drain, or overwhelm a downstream dependency? Do health checks remove already scarce capacity? Does it recover automatically when demand falls?

Those questions tell us more about scalability and resilience than whether a replica count moved from ten to twenty.

They also describe how a scaling policy should be treated from day one. Autoscaling configuration isn’t just infrastructure boilerplate that a service inherits and then forgets, it’s an executable statement of how we believe demand, capacity, performance, and cost relate to one another, and that statement is a hypothesis which should be continuously recalibrated with production evidence.

So, should we “believe” in autoscaling?

The PlanetScale customer who says, “It literally just autoscaled,” is describing a successful product boundary. Sam is also right to be proud of that response: a customer mistaking a difficult systems problem for an effortless product capability is often evidence that the platform team got the complex part right.

The mistake is still the one from the top: “My service autoscaled, therefore my system is scalable.”

A managed service can absorb a great deal of complexity within its boundary. It can’t automatically define useful work for our business or scale every dependency in the request path. It can’t decide which work should be rejected during overload, or whether preserving availability required an economically unreasonable amount of infrastructure.

This is why I would word it differently than Sam. Experience shouldn’t make belief in autoscaling decline; it should make it conditional. We can trust (much more than before) an autoscaler we have tested past its limits and wrapped in the overload controls that take over when capacity can’t arrive.

The position I have is neither blind faith in autoscaling nor reflexive distrust of it.

It is understanding:

• which resource is scaling;
• which signal drives it;
• how long the response takes;
• which assumptions the platform has absorbed;
• where the abstraction ends;
• what bottleneck comes next;
• how the system behaves at its limit;
• and what each completed unit of useful work ultimately costs.

Autoscaling is a behavior of a resource, scalability is a property of the request path.

Good autoscaling makes capacity changes feel boring.

Good systems engineering understands everything that still has to be true for that boring experience to remain safe, resilient, and economically sustainable.