The part worth studying is the retreat from cgroups. An earlier version of this autoscaler hung memory decisions off the cgroup `memory.high` event, and crossing that threshold makes Linux reclaim memory and throttle every process inside the cgroup [11]. That design measured memory pressure by waiting to be punished for it. Polling replaced it because polling proved more predictable and stable, and it still yields a 100-millisecond view of what Postgres is using [11]. That inner loop runs fifty times more often than the autoscaler-agent's read of overall VM memory metrics [3], which is the correct asymmetry: brief CPU over-commit makes queries slower, while allocating past the VM's RAM lets the kernel terminate processes [12].
The working-set signal is the one I would take to my own design. When a page is not local, the compute fetches it from the pageserver and caches the result in the Local File Cache, a disk-backed cache sized to fit in the kernel page cache and acting as a resizable extension of shared buffers [13]. Misses therefore park queries on network waits, which lowers CPU utilisation exactly when a bigger cache would help, and for many OLTP workloads performance changes sharply once the working set fits locally [14]. A utilisation-only autoscaler reads that as an idle machine and shrinks it. Counting every accessed page exactly would need too much memory, so the size is estimated [15]; the text supplied to me stops before naming the estimator.
Now the headline number. Neon reports 32,016 compute size changes per month for the average production database, or roughly one every 81 seconds [3]. The arithmetic checks: a 30-day month is 2,592,000 seconds, and dividing by 32,016 gives 81 [1]. It also works out to about 1,067 changes a day, near 44 in an hour [2], which is the density you would expect in the one-hour sample chart the Databricks copy uses instead [16]. For that rate to describe your database, two things have to hold. Your load has to actually move on a minute scale, and your configured minimum and maximum have to be far enough apart that the algorithm has somewhere to go. A steady service at constant QPS would resize rarely, and the win would appear on the invoice rather than on the chart.
Which brings back the decision the pitch says is gone. It is not gone, it is re-expressed: the target is the largest of `cpuGoalCU`, `memGoalCU` and `lfcGoalCU`, clamped to the minimum and maximum compute sizes the user configured [7]. So you still size, once, as a range. The difference that matters is what being wrong costs. Set the maximum too low and you get slower queries under the 90% CPU goal and the 75% memory goal [8][9], which leave 10% and 25% headroom respectively [4]. Set it too high and the most pessimistic of three signals decides your bill. That is a better failure surface than a fixed instance class, and it is available only if the box holding Postgres holds none of the data [5].
