Neues vom PostgreSQL Planet

© Laurenz Albe 2025

Starting with arrays in PostgreSQL is as simple as declaring a column as integer[], inserting some values, and you are done.

Or building the array on the fly.

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

This is a significant feature release that expands the scope of analysis to include several new modules and a visualization update:

Why static batch size configuration breaks down in real world networks and how automatic batch size tuning improves snapshot throughput.

Meet the mentee: Anushka Saxena worked with the project maintainers on transforming the documentation for CloudNativePG, as part of the LFX mentorship program.

PostgreSQL 19 changes this week cumulative statistics support for reading/writing auxiliary data from/to disk added pg_createsubscriber support for handling existing publications added pg_sync_replication_slots()  retry logic added PostgreSQL 18 articles PostgreSQL 18 Asynchronous Disk I/O - Deep Dive Into Implementation (2025-12-15) - Josef Machytka / Credativ

more...

When the database won't start and there's no backup available, most teams assume the game is over. But that's not true—the data is still on disk, it just lost the ability to speak. PostgreSQL data files remain transparent and readable, but here's the problem - without the data dictionary, you cannot understand what those bytes actually mean.

When people first hear "instant recovery," they often assume it is a replacement for backup—or worse, a risky shortcut only experts should attempt. But the truth is exactly the opposite. Instant recovery does not challenge any design boundary of PostgreSQL.

PostgreSQL 19 changes this week ALTER TABLE ALTER TABLE ... SPLIT PARTITION ... syntax added ALTER TABLE ... MERGE PARTITIONS ... syntax added pg_stat_progress_analyze column started_by added pg_stat_progress_vacuum columns mode and started_by added vacuumdb option --dry-run added PostgreSQL 18 articles Postgres 18 New Default for Data Checksums and How to Deal with Upgrades (2025-12-11) - Greg Sabino Mullane / Crunchy Data

more...

Back in September 2025, David Fetter asked on IRC, about a tool to quickly load CSV to database. One that would require minimal configuration, will try to figure out as much as possible on its own. I thought that it would be great idea. Plus, I'm trying to learn more JavaScript / Node, so figured … Continue reading "Quick and dirty loading of CSV files"

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.