The archiver only runs when a WAL segment is complete. On a busy database that happens constantly; on a quiet one it might not happen for hours or days. archive_timeout exists to prevent the resulting “our database has been accepting writes all afternoon but none of them are in the archive yet” problem.
First in a series of dispassionate surveys of the major managed-Postgres offerings. This post is about Amazon RDS for PostgreSQL — what AWS calls “traditional RDS,” as distinct from Aurora PostgreSQL, which is a separate product with a separate architecture and will get its own post.
Every few months somebody publishes a “state of open source licensing” piece, and most of them aren’t worth your time. This one is.
Gabriel Anhaia’s Open Source in 2026: The Fork Wars Are Getting Ugly pulls the year’s licensing disasters — OnlyOffice trying to weaponize AGPLv3 §7 against Nextcloud, IBM-flavored HashiCorp grinding away at OpenTofu contributors, Cal.com’s “AI made
Stephen O’Grady’s State of Open Source Licensing in 2026 at RedMonk is essential reading. The headline finding — that the long shift from copyleft to permissive licensing has continued, with Apache and MIT consolidating their dominance among the survivors — surprises no one who has been watching the space. The interesting question, as always, is what the data leaves out.
PostgreSQL 19 ships with parallel autovacuum. The new GUC autovacuum_max_parallel_workers caps the cluster-wide pool, and the per-table storage parameter autovacuum_parallel_workers lets you tune individual tables. Workers come out of the existing max_parallel_workers budget. Off by default. Good.
This is a real improvement, and a lot of people are going to turn it on for the wrong reasons.
archive_mode is the master switch for WAL archiving. With the last three posts under our belts — archive_cleanup_command, archive_command, archive_library — we now get to the parameter that decides whether any of that machinery runs at all.
Three values: off (default), on, and always. Context is postmaster, which means flipping it requires a server
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 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
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
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.