Sammlung von Newsfeeds

PostgreSQL 19 adds GRAPH_TABLE, letting you query property graphs with Cypher-like pattern matching over your existing relational tables.

On May 26 2026, the Bratislava PostgreSQL Meetup came together, organized by Pavlo Golub and Meego Smith. Mayur B. and Devrim Gündüz delivered a presentation.

About 90 attendees showed up for the NYC Postgres meetup that took place May 27 with Gleb Otochkin speaking.

Organizers:

A round up of the sixth PGConf.be

The shared presentations are online, as are a couple of recordings and turtle-loading have-a-cup-of-tea locally stored photos.

Skip partition scanning with constraint_exclusion, PostgreSQL's old pruning trick.

PostgreSQL's `config_file` parameter creates a bootstrap paradox: it tells the server where to find its configuration, but lives on the command line only—never…

PostgreSQL 14 unified query-id computation across all subsystems, but defaulting to always-on would tax every backend.

PostgreSQL finally has an open-source Transparent Data Encryption option.

Postgres has had a thorn in its paw for a very long time regarding table size. Every modified tuple leaves an old version in the heap for use by older transactions. While  locates these old tuples, it only marks them as reusable rather than returning the space to the OS. Tables only ever grow larger in Postgres.Maybe Postgres 19 can fix that for us.

Last week, we attended the annual PGConf.dev as a Gold-level sponsor. While most PostgreSQL conferences usually attract users and DBAs, this event draws a strong mix of contributors and community members alike, making it a unique opportunity to get proposals and patches reviewed and to connect across the broader Postgres ecosystem. 

PostgreSQL 17 made SLRU buffer pools configurable for the first time.

Thanks to the organising team, I had the chance to attend PGConf.dev last week in Vancouver, Canada. And luckily, I wasn’t alone there — Valeria could join as well!

This year’s edition was particularly special: we celebrated 30 years of open source PostgreSQL together! Many activities revolved around the anniversary, including a special celebration-themed conference t-shirt, stickers, commemorative posters, and more.

Three heap buffer overflows in PostgreSQL — including a 20-year-old pgcrypto bug — were found by an AI code analyzer. But.

A field report from PGConf Dev 2026 — and a working framework for everyone who has to keep AI workloads running in production.

It’s 3:47 AM. The Pager Goes Off.

A production AI batch job is stuck. Sixty thousand rows are locked. Your application performance is degrading. The post-mortem the next morning will be filed under “unknown cause.”

If you have a slow query, one of the obvious moves is to add an index. So you look at the WHERE clause, pick a column, run CREATE INDEX, and test again. Sometimes it helps, often it doesn’t. And now you have an index sitting there, not helping reads, but slowing down every write, because INSERT, UPDATE, and DELETE all have to maintain it. And it gets worse as your system grows.

Logical replication has come a long way since its introduction in PostgreSQL. It is now being adopted more widely than ever, powering cross-version upgrades, multi-region deployments, and real-time analytics pipelines. Yet significant opportunities for improvement still remain.

 

Tune `commit_delay` to batch WAL flushes and trade latency for throughput—but only if `pg_test_fsync` proves sync time is your bottleneck.

PostgreSQL 19 brings REPACK CONCURRENTLY, a native alternative to pg_repack that rewrites tables without crippling locks.

This series is aimed at recounting, explaining, and cataloging issues pertaining to Postgres in large-scale production environments that affected a wide section of users and clients. The idea occured to me when discussing one specific issue (covered in a later part in this series) that was my first experience dealing with such issues on a wide scale (multiple clients and clusters affected). This specific part focuses on issues that were caused not by Postgres itself, but by the tools, OS, and ecosystems that Postgres relies on.

The Iceberg tables look like normal Postgres tables. You create them with USING iceberg and they're backed by Parquet on S3:

Postgres engines now have access to more data than ever. With extensions like pg_lake, you can connect Postgres to gobs of files in object storage like csv, json, Apache Parquet™ and Apache Iceberg™.

cluster_name looks like a cosmetic label for process listings, but on a standby it silently becomes the name your primary uses to verify synchronous…