VACUUM is often not the thing that cleans up most bloat in Postgres. There is also HOT pruning: https://github.com/postgres/postgres/blob/master/src/backend/ac

VACUUM is often not the thing that cleans up most bloat in Postgres. There is also HOT pruning: https://github.com/postgres/postgres/blob/master/src/backend/access/heap/README.HOT#L181 https://github.com/postgres/postgres/blob/master/src/backend... Separately, certain index access methods, most prominently B-Tree, support on-the-fly deletion of index tuples: https://github.com/postgres/postgres/blob/master/src/backend/access/nbtree/README#L378 https://github.com/postgres/postgres/blob/master/src/backend... Neither of these things need VACUUM to run. They can happen entirely dynamically. An important point is that there are fine distinctions between the kinds of bloat that exist, distinctions that matter if you want to account how things work for the purposes of a technical deep-dive, but often matter a lot less in the real world. For example, PostgreSQL isn't overly concerned about making free space reclaimable by the operating system, particularly in the shortest possible timeframe.