Neues vom PostgreSQL Planet

Introduction

PostgreSQL's query planner relies on table statistics to estimate the number of rows (estimated rows) each operation will process, and then selects an optimal execution plan based on these estimates. When the estimated rows diverge significantly from the actual rows, the planner can choose a suboptimal plan, leading to severe query performance degradation.

Saw this post on LinkedIn yesterday:

You can prototype an impressive agent in a notebook, but you can’t run one in production without a transport strategy. The Model Context Protocol standardizes how agents call tools and access memory, but it intentionally does not define how bytes move between systems. That responsibility sits with your architecture. Most teams treat transport as an implementation detail, and default to whatever works in a development container. That shortcut becomes technical debt the moment the system faces real traffic. The symptoms are predictable: 

Over 15 years later, some solutions are still great solutions Introduction

OpenAI recently shared their story about how they scaled to 800 million users on their ChatGPT platform. With the boom of AI in the past year, they’ve certainly had to deal with some significant scaling challenges, and I was curious how they’d approach it. To sum it up, they addressed the following issues with the following solutions:

A major architectural milestone that removes schema logs and simplifies how pgstream captures and replicates Postgres schema changes

PostgreSQL 18 introduces native "Skip Scan" for multicolumn B-tree indexes, a major optimizer enhancement. However, a common misconception is that pre-v18 versions purely resort to sequential scans when the leading column isn't filtered. In reality, the cost-based planner has long been capable of leveraging such indexes when efficient.

How it works under the hood:

The following thoughts and comments are completely my personal opinion and do not reflect my employers thoughts or beliefs. If you don’t like anything in this post, reach out to me directly, so I can ignore it ;-).

The Pain and the Real Constraint

Your dashboard queries are timing out at 30 seconds. Your BI tool is showing spinners. Your users are refreshing the page, wondering if something’s broken.

You’ve indexed everything. You’ve tuned shared_buffers. You’ve rewritten the query three times. The problem isn’t bad SQL – it’s that you’re forcing PostgreSQL to aggregate, join, and scan millions of rows every single time someone opens that report.

The topic of checkpoint tuning is frequently discussed in many blogs. However, I keep coming across cases where it is kept untuned, resulting in huge wastage of server resources, struggling with poor performance and other issues. So it’s time to reiterate the importance again with more details, especially for new users. What is a checkpoint? […]

When you are planning database migrations to PostgreSQL, it is usually the small things that cause the biggest production bugs. One of the most common traps for developers is how different databases handle NULL and empty strings ('').

The Nordic PGDay 2026 Call for Paper Committee met to finalize the talk selection:

• Georgios Kokolatos
• Louise Leinweber
• Liisa Hämäläinen
• Thea Stark

PGDay Paris 2026 schedule has also been announced — talk selection was made by:

The new major release of the fast connection pooler for PostgreSQL has been released!

pgagroal 2.0.0 is available!

It took quite a lot of time to get from version 1.6.0 to the new major version 2.0.0, but the new pgagroal is finally here! The project went thru two Google Summer of Code (GSoC 2025 and 2024) before this new great release was completed, but the project decided to prefer the code stability over the rush in releasing, and I think you are going to be amazed by how much improvements have been collapsed in this new version.

Last year at pgconf.dev, there was a discussion about improving the user interface for the PostgreSQL hackers mailing list, which is the main communication channel for PostgreSQL core development. Based on that discussion, I want to share a small project we have been working on:

https://hackorum.dev/

The Honor Part (That I’m Still Processing) 🔗Let me start with the big one: I was invited to the European Open Source Awards ceremony on Thursday evening. Not “bought a ticket” invited—actually invited. If you know the European Union, you know this is invitation-only, and honestly, I’m still a bit stunned. So, picture me, finally seated in my seat on the train, ready to go and checklisting everything. I have the dress, the belt, the purse, the jewels, even the hair accessories.

Read time: ~6 minutes

A real-world deep dive into operator precedence, implicit casting, and why database engines “don’t think the same way”.

The Database Migration Mystery That Started It All

You migrate a perfectly stable Oracle application to PostgreSQL.

I have to apologise — it's been months since PGConf.EU 2025 in Riga, and I'm only now publishing this video. The delay was due to wanting to create accurate captions for the recording, which unfortunately took longer than expected.

In this session, Floor Drees, Karen Jex, and I joined host Boriss Mejias to examine how diverse minds work together in the PostgreSQL ecosystem. We touched upon the psychology of teamwork and the importance of accommodating neurodiverse conditions like ADHD and ASD.

PostgreSQL can scale extremely well in production, but many deployments run on conservative defaults that are safe yet far from optimal. The crux of performance optimization is to understand what each setting really controls, how settings interact under concurrency, and how to verify impact with real metrics.

This guide walks through the two most important memory parameters:

The rise of agentic AI is transforming how we build applications, and databases are at the center of this transformation.

A query executes in just 2 milliseconds, yet its planning phase takes 500 ms. The database is reasonably sized, the query involves 9 tables, and the default_statistics_target is set to only 500. Where does this discrepancy come from?

I just gave a new presentation at Prague PostgreSQL Developer Day titled What's Missing in Postgres? It's an unusual talk because it explains the missing features of Postgres, and why. One thing I learned in writing the talk is that the majority of our missing features are performance-related, rather than functionality-related. I took many questions: