Sammlung von Newsfeeds

It's that time again. The upcoming Postgres v18.4 release (along with minor releases for all Major versions) has dropped some serious hints in the git logs, and it's bringing a significant payload of CVE tagged patches. As a seasoned Postgres end-user and an erstwhile DBA, whenever I see a flurry of high-vulnerability security commits, I immediately start recommending that customers begin planning their patching cycles.

A heap buffer overflow in pgcrypto's OpenPGP code lurked for two decades—until a December 2025 exploit made it real.

I'm excited to announce release 1.0 of pg_statviz, the minimalist extension and utility pair for time series analysis and visualization of PostgreSQL internal statistics.

A step-by-step guide to migrating a PostgreSQL 17 cluster managed by Crunchy PGO v6 to PostgreSQL 18 under CloudNativePG. Two paths are covered: a fully declarative offline migration using CloudNativePG’s built-in pg_dump import, and an online migration using native PostgreSQL logical replication for a near-zero-downtime cutover.

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.