Neues vom PostgreSQL Planet

On December 10th, 2025, the PostgreSQL December Meetup in Frankfurt (Main) took place. We had two speakers, and a nice dinner. This Meetup was organized around the IT-Tage, and the Meetup organizers had booked a reeting toom in the Scandic Frankfurt Museumsufer. About 15 minutes walking from the conference, and unfortunately it was raining that evening. Meeting room Dirk Aumueller: Running PostgreSQL with Podman, Quadlet & Systemd Dirk spoke about how to run PostgreSQL inside a Podman Quadlet which is managed by systemd.

As you maybe know, some time ago I made paste service, mostly to use for queries, or related text to share on IRC. One part of it is that it also has pretty printer of provided queries. Recently I realized that in case of complex join conditions, the output is, well, sub-optimal. For example: SELECT … Continue reading "Small improvement for pretty-printing in paste.depesz.com"

One of things people learn is that adding indexes isn't free. All write operations (insert, update, delete) will be slower – well, they have to update index. But realistically – how much slower? Full tests should involve lots of operations, on realistic data, but I just wanted to see some basic info. So I figured … Continue reading "What is index overhead on writes?"

I am writing this post over the weekend but scheduling it to be published on Tuesday, after the PG DATA CfP closes, because I do not want to distract anyone, including myself, from the submission process.

A couple of months ago, I created a placeholder in my GitHub, promising to publish pg_acm before the end of the year. The actual day I pushed the initial commit was January 3, but it still counts, right? At least, it happened before the first Monday of 2026!

I do a fair amount of benchmarks as part of development, both on my own patches and while reviewing patches by others. That often requires dealing with noise, particularly for small optimizations. Here’s an overview of ways I use to filter out random variations / noise.

Most of the time it’s easy - the benefits are large and obvious. Great! But sometimes we need to care about cases when the changes are small (think less than 5%).

PostgreSQL 18 made one very important change – data block checksums are now enabled by default for new clusters at cluster initialization time. I already wrote about it in my previous article. I also mentioned that there are still many existing PostgreSQL installations without data checksums enabled, because this was the default in previous versions.

Introduction

PostgreSQL has built-in support for logical replication. Unlike streaming replication, which works at the block level, logical replication replicates data changes based on replica-identities, usually primary keys, rather than exact block addresses or byte-by-byte copies.

PostgreSQL 18 has arrived with some fantastic improvements, and among them, the RETURNING clause enhancements stand out as a feature that every PostgreSQL developer and DBA should be excited about. In this blog, I'll explore these enhancements, with particular focus on the MERGE RETURNING clause enhancement, and demonstrate how they can simplify your application architecture and improve data tracking capabilities.

Most teams assume data loss means restore from backup. This article introduces the Instant Recovery mindset, explains why PostgreSQL makes it possible, and how PDU turns recoverability into a practical, predictable process.

In this post, I describe experiments on the write-versus-read costs of PostgreSQL's temporary buffers. For the sake of accuracy, the PostgreSQL functions set is extended with tools to measure buffer flush operations. The measurements show that writes are approximately 30% slower than reads. Based on these results, the cost estimation formula for the optimiser has been proposed:
flush_cost = 1.30 × dirtied_bufs + 0.01 × allocated_bufs.

Recently during a post-migration activity, we had to populate a very large table with a new UUID column (NOT NULL with a default) and backfill it for all existing rows.

Instead of doing a straight:

ALTER TABLE ... ADD COLUMN ... DEFAULT ... NOT NULL;

we chose the commonly recommended performance approach:

A client accidentally ran rm -rf /*, wiping out the entire OS and database. After disk recovery experts salvaged the data files, PDU adapted to this domestic PostgreSQL variant and completed full data recovery in just 4 hours.

When pg_type and pg_attribute are partially destroyed, how do you piece together a corrupted database? This real-world case reveals an ingenious workaround that saved 46% of the data.

DROP TABLE with no backup? Most consider it game over. Discover how PDU achieves the "impossible" - scanning raw disk blocks and matching table structures to resurrect your lost data.

A corrupted disk. A dead database. Unusable backups. 1.5TB of critical business data hanging by a thread. This is the story of how PDU turned an impossible situation into a triumph.

Meet the mentee: Yash Agarwal worked with the project maintainers on adding chaos testing to CloudNativePG, as part of the LFX mentorship program.

PostgreSQL 19 changes this week pg_stat_replication_slots newly added column  slotsync_skip_at renamed to slotsync_last_skip pg_dsm_registry_allocations improvments to display of the size of DSAs and dshashes PostgreSQL 18 articles A deeper look at old UUIDv4 vs new UUIDv7 in PostgreSQL 18 (2025-12-05) - Josef Machytka / Credativ

more...

On 14th of December 2025, Alexander Korotkov committed patch: Implement ALTER TABLE ... MERGE PARTITIONS ... command   This new DDL command merges several partitions into a single partition of the target table. The target partition is created using the new createPartitionTable() function with the parent partition as the template.

We talked to Matthew Mols, Sr. Director of Engineering at pgEdge, about how CloudNativePG enables them to meet the requirements of their customers using just open source.

2025 marked a historic turning point for CloudNativePG, headlined by its acceptance into the CNCF sandbox and a subsequent application for incubation. Throughout the year, the project transitioned from a high-performance operator to a strategic architectural partner within the cloud-native ecosystem, collaborating with projects like Cilium and Keycloak. Key milestones included the co-development of the extension_control_path feature for PostgreSQL 18, revolutionising extension management via OCI images, and the General Availability of the Barman Cloud Plugin.