Sammlung von Newsfeeds

PGConf Belgium took place on 5 May 2026, organized by Wim Bertels, An Vercammen, and Grégory Gioffredi , who served also at the talk selection team.

Speaker:

PostgreSQL's complicated relationship with the Linux page cache spawns four GUCs to manage writeback—and backend_flush_after is the conservative one.

#​648 — May 13, 2026

Web Version

Postgres Weekly

Strong Views on Postgres VIEWs — Why views are clean to use but painful to change in Postgres, with a tour of how they work under the hood and what’s missing from ALTER VIEW. Surprisingly, the mechanism that would fix it already exists inside pg_dump…

Radim Marek

Three major cloud platforms just shipped Postgres with custom storage engines and scale-out architectures.

Google's managed PostgreSQL returns to first principles: a conventional instance on a VM with a regional disk, plus a distinctive data cache on Enterprise Plus…

Last week, Zsolt and I jumped on a call with someone who had been building something remarkably similar to what we had been working on, completely independently. That someone is Jack Bonatakis, the creator of pginbox.dev, and that call turned into one of the most energizing conversations we’ve had since launching hackorum.dev.

PostgreSQL 18 splits autovacuum configuration to finally let you tune worker concurrency without restarting.

Deploy ParadeDB on Render with one click. Full-text search, vector search, and hybrid search over Postgres — now available on your favorite cloud platform.

Bit of a news catchup on the pg_clickhouse project.

What’s New

First up, a couple weeks ago the ClickHouse Blog published What’s New in pg_clickhouse, in which I covered various improvements to the extension:

A beginner’s guide to encrypting your database connections

“’SSL is enabled’ and ‘SSL is actually working’ are two very different things.”

PostgreSQL 19 finally lets wal_level adapt dynamically to your actual replication slots, eliminating the always-on WAL cost of logical standby insurance.

Introduction

Over the past year, I’ve worked in a handful of contexts managing large volumes of data stored as JSONB in PostgreSQL. The scenario is common: users appreciate the flexibility of a document-oriented storage model, avoiding the need to predefine schemas or constantly migrate table structures as their data requirements evolve. JSONB documents can be deeply nested with numerous optional fields, and they scale to hundreds of kilobytes per record without issue.

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 indep…

Autovacuum's most powerful tuning lever: the scale factor that determines when dead tuples trigger a vacuum. On large tables, the 20% default waits too long.

VIEWs should be the cleanest abstraction SQL, and therefore Postgres, has on offer. I love the concept. The promise of decoupling logical intent from physical storage is perfect on paper. In practice, few things in the database world trigger such a heated debate or carry as much historical baggage. VIEWs mix big promises with false hopes, and the promises rarely survive contact with production.

PostgreSQL 18 finally fixes the autovacuum formula that left billion-row tables waiting for 200M dead tuples.

Six years after PostgreSQL shipped the table access method API, the alternative storage engine ecosystem is thriving—but messier than early predictions…

Snowflake's pg_lake and Databricks' Lakebase both wrap PostgreSQL for lakehouse workloads, but they're nearly opposite architectures.

Recently at Postgres Conference 2026 in San Jose, I presented a talk called Let's Build a Postgres Extension! Since that entire presentation was primarily focused on writing a C extension while exploring the Postgres source code, I only mentioned pure SQL extensions as an aside.

PostgreSQL 13 added insert-triggered autovacuum to solve a critical problem: append-only tables never vacuumed, breaking index-only scans and delaying tuple…