I guess this is just phrased a bit oddly. It's just a factor in helping us scale by requiring us to use our hardware more efficiently. Not sure I'd say it's horizontally or vertically. We've just made each unit of work cheaper to help things along.

It's vertical almost by definition. I'll say it.

I don't think it's either. "Scaling" refers to growing the amount of compute power you are using. This change falls into a different bucket, which is making more efficient use of the compute that's already available.

If they are running multiple Docker containers, the improved efficiency would allow them to run more containers per host computer. Maybe that's what they meant, although it's not really horizontal scaling either.

I think scaling is more about serving demand - whether you you use more resources on a single box, more resources by using more boxes or use the same resources more efficiently you're still scaling.

This is the closest to my use of the term. I'd go further and say that using more resources on a single box is vertical scaling, using more boxes is horizontal, and this thing is neither. How about density scaling?

A previous HN discussion proposed the term "scaling deeper".

Scaling Horizontally - spending resources on adding more nodes to a cluster, so more work can get done in parallel. Scaling Vertically - spending resources on adding computational power to individual nodes, so an individual job can get done faster. Scaling Deeply - spending resources on understanding and optimizing an application, so each job can get done with less computational power.

Each of these can be thought of as an orthogonal axis, with its own curve of diminishing returns.

Why does it have to do with scaling in the first place?

Performance has nothing to do with scalability whatsoever, by the way.

If you halve the memory and CPU usage of a given service (that's not IO bound), have you not improved it's vertical scalability?

Not if those things aren't the bottleneck. Scalability is such a buzzword. The correct term is "performance" or "overhead". Scalability matters when you're talking about an entire system that you're deploying on many machines -- the problem space and technical discussion is different to fixing a performance issue in Python.

David from Sentry here. I've got a long history of talking about scale in the python/web ecosystems. I'll echo what some others have said: scale is fundamentally a business metric.

If we can do more with less machines it's no different than doing more with more machines. We added triple our infrastructure to handle the Python load while we resolved this CPU issue, and that wasn't "scaling" (literally, it causes other scale concerns).

Fixing the root cause let's us drop all of those new machines as well as some older ones. The scalability of the system has greatly increased because of this and other factors -- primarily that many or all systems aren't actually "horizontally" scaleable.

Unless we know where the application is bottlenecked, it's hard to say how this affects scaling. Reducing CPU usage may have no real effect on scalability if IO is what's keeping them back.