Neues vom PostgreSQL Planet

PostgreSQL 18's `file_copy_method = clone` can copy a terabyte database in half a second on copy-on-write filesystems. Here's when and why you should use it.

Changing a PostgreSQL backup solution involves much more than installing a new binary. Backup repositories, retention policies, recovery procedures, operational runbooks, and compliance requirements have all been built over time. Any migration needs to fit into that operational landscape while preserving confidence in recovery. That thinking shaped the migration approach behind pg_hardstorage.

extra_float_digits is the setting whose job changed out from under it. For most of PostgreSQL’s history it forced a choice between floating-point output that was easy to read and output that was exactly right, and you could not have both. Since PostgreSQL 12 you no longer have to choose, which is…

On July 15, we hosted the second meetup at our new location, the Chicago Innovations Center. The CIC is evolving, and we like it more and more! I will probably stop saying it at some point, but for now, I want to repeat it one more time: we hope it will be our permanent home!

I wonder what we can confidently say about how AI is changing the way our community works.

Write a second PID file to a custom location—useful when your cluster manager expects PostgreSQL's PID at a specific path like `/run/postgresql/postgresql.pid`.

PostgreSQL 18 lets you store extensions anywhere with `extension_control_path`, ending the requirement to install them into the system directory.

Postgres 19 is just a smorgasbord of new functionality; it's genuinely hard to believe they packed all these new features into a single release. To that laundry-list of new capabilities, it adds something I almost missed. We all know and love the Postgres Write Ahead Log (WAL), where all writes begin their lives.

PostgreSQL's `exit_on_error` GUC promotes every error to a session-terminating event—but this fail-fast illusion masks a destructive truth.

Spock 6 has landed in Beta. pgEdge's multi-master replication extension now runs on PostgreSQL 16, 17, 18, and 19, tracks replication progress in shared memory instead of a catalog table, spills oversized replay queues to disk, and reports conflict statistics per subscription. Spock 5 was already doing the hard work of multi-master replication in production.

Postgres 19 is planning to change the default TOAST compression from pglz to LZ4, so let's look at how Postgres compresses data in table storage and indexes. Postgres uses a single, unified compression framework for table (heap), TOAST, and indexes. In heap and TOAST, compression is automatic and on by default for variable-length types like TEXT, VARCHAR, BYTEA, and JSONB. In indexes, it is opportunistic: compression fires only when an individual key exceeds the size threshold, not for every variable-length value stored in an index.

click to expand

When you are upgrading across major PostgreSQL versions, there are a few ways to go. Dump and restore is the simplest to reason about, but downtime scales directly with database size, so for anything multi-terabyte, it is off the table. Logical replication gets you near-zero downtime, but it only works from PostgreSQL 10 onward; if your source cluster is on less than version 10, that path does not exist in a native way. That leaves pg_upgrade, the community-maintained tool for in-place major version upgrades.

Six months ago we started writing the PostgreSQL backup tool we kept wishing existed. Now pg_hardstorage has shipped, and you can read every line of it on GitHub before you trust it with your WAL stream.

Event triggers fire on DDL and login events, not rows—and a buggy one can lock out every user, even superusers.

Slides and transcript from How much do you really need to know about databases? at EuroPython 2026 in Kraków, Poland on 15 July 2026.

I will add a link to the recording once it's available.

I've included just very brief alt-text for each slide image, but I've also added any links or other essential information into the body of the blog post.

POSETTE: An Event for Postgres 2026 is an online event for PostgreSQL, brought to us by the Postgres team at Microsoft, which took place on June 16-18, 2026. I'll always have a soft spot for in-person conferences, but POSETTE is probably the best-run online event in our community, and I was delighted to be invited back to speak.

Windows PostgreSQL logs messages to the Event Log under a name you choose with `event_source`—but Windows won't understand that name until you register it with…

As stated in Part 1, pgAgent is going away, so I'm focussing on setting up pg_timetable as similar to pgAgent that I can. For this second part, I'm going to go over how to configure pg_timetable as a service on Linux.

Back on Friday, April 3rd, I ran a live, hands-on LinkedIn Live session on fixing bad SQL in PostgreSQL. My apologies for the delay in sharing the recording: for various reasons I couldn't post it earlier, but here it is.

This post is about what PostgreSQL actually does when you write GRAPH_TABLE syntax. It turns out the database rewrites your graph query into ordinary joins against the underlying tables, then plans them with the regular optimizer. This has three practical consequences you'll notice right away.