In the last twelve months, three of the biggest data-platform companies have shipped a Postgres-flavored database with a custom storage layer and a “scale-out compute, shared storage” architecture. Snowflake Postgres is GA, built on the Crunchy Data team’s work, with pg_lake as the lakehouse hook. Databricks Lakebase is GA on AWS, public preview on Azure, built on the Neon engine

The last entry in the autovacuum cluster, and the newest. PostgreSQL 18 introduced autovacuum_worker_slots to solve a long-standing operational annoyance: changing autovacuum_max_workers used to require a server restart, which made it impossible to respond to evolving vacuum workload without a maintenance window. PG 18 fixes that by splitting the parameter in two.

For as long as logical replication has existed in PostgreSQL, the rule has been: if you ever might want to use it, set wal_level = logical at server start and live with the WAL volume forever. The cost wasn’t disastrous, but it was always-on. Set it once, pay it forever, including for the 364 days a year you weren’t using

autovacuum_work_mem sets the maximum memory each autovacuum worker may use for tracking dead tuple identifiers (TIDs) during a vacuum. Default is -1, which means “inherit from maintenance_work_mem.” Context is sighup. The parameter exists so that autovacuum’s memory consumption can be tuned independently of the memory used by manual VACUUM, CREATE INDEX, REINDEX, and other

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