Yesterday David Steele announced that he is stepping away from pgBackRest. After thirteen years, the most widely-deployed dedicated backup tool in the PostgreSQL ecosystem is no longer maintained. The current release, v2.58.0, is the last release. Steele asks that any forks pick a new name, which is — among other things — an act of professional courtesy from a maintainer

For about fifteen years the answer to “can I turn on data checksums without an initdb?” has been “not really.” pg_checksums showed up in PostgreSQL 12 and made the job survivable, but you still had to shut the cluster down. For anyone running 24×7 production, that has left the same three options: take the downtime, fail over through a

For thirty years, the answer to “how do I get the DDL for this object?” in PostgreSQL has been: shell out to pg_dump -s and grep. Every tool that has ever needed to reconstruct an object definition — migration tools, schema diff utilities, \d replacements, every ORM that has tried to introspect a live database — has either invoked pg_dump

Before getting into this one, an errata against the previous post. I said backup tools “can register as an archive_library and bypass archive_command entirely” on PostgreSQL 15+. That is what the feature was designed to enable. It is not what the ecosystem has actually shipped. More on that in a moment.

archive_library, added in PostgreSQL 15, lets you

Last post’s deferred party has arrived. archive_command is how WAL segments leave the primary and travel somewhere durable — the substrate on top of which point-in-time recovery, warm standbys, and every serious backup tool are built. It is also, in the classic formulation, a shell command written on one line of postgresql.conf. This is as terrifying as it sounds.

Alphabetical order delivers our first casualty. archive_cleanup_command is a standby-server knob that exists entirely to tidy up after archive_command, which the alphabet insists on deferring until the next post. So we will describe how to sweep up a party we have not yet thrown.

The briefest-possible backfill: a PostgreSQL primary can archive its WAL segments to some location

The previous post on the Linux 7.0 pgbench regression ended with the same instruction every other Postgres performance post ends with: set huge pages. This post is the long version. If you have read the Postgres docs on huge_pages and you’re still not completely sure what /proc/meminfo is telling you, what the relationship is between vm.nr_hugepages and Transparent Huge

Last year’s acquisitions have now shipped products, and for the first time it is possible to compare the Snowflake and Databricks “Postgres-in-the-lakehouse” strategies as real things rather than as marketing decks.

The acquisitions: Snowflake bought Crunchy Data in June 2025 (around $250M) and released pg_lake as open source under Snowflake-Labs in November. Databricks bought Neon in May 2025 (around

Most GUCs in this series will be operationally irrelevant to most readers. This one is not. application_name is the single cheapest piece of observability infrastructure PostgreSQL ships, and an astonishing number of production databases are running with it unset or stuck at a client library’s default (psql, PostgreSQL JDBC Driver, or — my favorite — the empty

A benchmark came out of AWS earlier this month showing PostgreSQL throughput on Linux 7.0 dropping to 0.51x what the same workload produced on Linux 6.x. The Phoronix headline wrote itself. Hacker News did what Hacker News does. By the end of the week, I had been asked by three separate clients whether they needed to hold their kernel upgrades.