Neues vom PostgreSQL Planet

If not first, pg_stat_statements is one of the most used extensions in the PostgreSQL ecosystem. It ships in contrib and costs almost nothing to use. Most of us turn to it to answer the question: what is the database actually doing? It's genuinely useful. You can use it to get a snapshot of what happened in a given timeframe, and make a faster decision about what to fix.

I was hoping to usual resume the monthly cadence of hacking workshops in June, but it didn't quite happen, largely due to being a little exhausted after pgconf.dev. But, I'm pleased to announce that Melanie Plageman will be joining us to discuss her talk Additional IO Observability in Postgres with pg_stat_io. If you're interesting in joining us, please sign up using this form and I will send you an invite to one of the sessions.

Azure's managed PostgreSQL differs from competitors by putting the standby in the commit path—every write waits for synchronous replication to a second server…

We were doing everything right. The migration plan was solid, the team was experienced, and we had done this kind of thing before. But somewhere around midnight, someone on the team noticed something strange. Tables on the destination side were ballooning at an unexpected rate with hundreds of gigabytes being used, while the source side tables sat quietly at just a few megabytes.

Something was very wrong, and we had no idea what.

© Laurenz Albe 2026

Instigated by a customer, I've been trying to improve the performance of row-level security. Central to good performance in this area is the concept of leakproof functions and operators. I'll go over the priciples quickly, but I'll focus on the question what leakproof really means, and what it should mean. In a way, this article is a request for comments: I'd be curious what you think about the topic!

cpu_tuple_cost, cpu_index_tuple_cost, and cpu_operator_cost are three of the constants the planner uses to price a query, and the single most useful thing to know about all three is that you should almost certainly never change them. The rest of this post is why. PostgreSQL’s planner does not est…

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.