The classic vacuum-trigger pair, finally. We have spent the last several posts on parameters that modify, cap, or supplement the trigger formula governed by these two; now we get to the originals.

The formula:

1
vacuum threshold = autovacuum_vacuum_threshold
2
                 + autovacuum_vacuum_scale_factor × reltuples

When the number of obsoleted tuples (rows updated or deleted) since

New in PostgreSQL 18. This parameter is the project’s first-class fix for a problem the entire community has been working around for roughly fifteen years: on very large tables, the default vacuum trigger formula waits absurdly long before doing anything.

The original formula:

1
vacuum threshold = autovacuum_vacuum_threshold
2
                 + autovacuum_vacuum_scale_factor × reltuples

With the

PostgreSQL 12 shipped the table access method API in October 2019, and the community spent the next six years figuring out what to do with it. The early prediction was that within a few releases we would have a thriving ecosystem of pluggable storage engines — columnar for analytics, undo-log for OLTP, in-memory for hot workloads — and the heap

Snowflake and Databricks are now both selling something called PostgreSQL, both pitched at the same general use case (“the operational database next to your lakehouse”), and both with the word “lake” in the product name. Snowflake calls theirs pg_lake (a set of open-source extensions, plus the managed Snowflake Postgres service that wraps them). Databricks calls theirs Lakebase (a managed service

These two are the third matched pair in the autovacuum suite, after the analyze pair and the regular vacuum pair (the latter coming up next). They control when autovacuum runs VACUUM against a table based on the number of inserts since the last vacuum — not updates, not deletes, just inserts. They were added in PostgreSQL 13, and they exist

“You never actually own a project, you merely look after it for the next generation.”
— with apologies to Patek Phillippe.

In early March 2026, Dan Blanchard published chardet 7.0.0. The package metadata was familiar — same name on PyPI, same import path, same public API. The license was not. Versions 1.1 through 6.x had shipped

PostgreSQL 19 widens MultiXactOffset to 64 bits, retiring one of the more interesting failure modes the database can produce in production. The members-space wraparound on the multixact SLRU was a genuine outage class — Metronome ate four of them in a single migration last May — and it is gone in 19. Good. Onward.

The obvious next question, asked

These three parameters together set the pace of autovacuum: how often it considers running, how hard it works while running, and how long it pauses to keep from monopolizing your I/O. Like the analyze pair, they are best understood as a unit.

Unsurprisingly, PGX is involved in a lot of database emergency responses. Every emergency is different, but there are some basic rules that everyone should follow for any emergency reponse.

–

• Wind your watch.

No one has a watch that winds anymore, but the point is: take a deep breath. Give yourself a minute, or two,

PostgreSQL 19 widens MultiXactOffset to 64 bits. The ceiling that has periodically taken down high-concurrency, FK-heavy clusters is gone — not raised, eliminated. If you have ever been paged at 3 a.m. because your monitoring noticed pg_multixact/members/ filling up faster than autovacuum could reclaim it, this is for you.