Latest Blog Posts

On 29 September, the PostgreSQL Usergroup NL met, organized by Gerard Zuidweg and Sebastiaan Mannem

Speakers:

• Peter Lengkeek
• Ellert Van Koperen
• Jan Karremans

The Postgres US Summit 2026 was held from 30 September to 2 October.

Organizers:

• Mark Wong
• Michael Alan Brewer
• Mila Zhou
• Chelsea Dole
• Pat Wright
• Joseph Koshakow

Program Committee:

• Chelsea Dole
• Jonathan Hinds
• Jonathan Katz

Code of Conduct Committee:

• Mila Zhou
• Michael Alan Brewer
• Katherine Saar

Speakers:

• Alex Anto Kizhakeyyepunnil Joy
• Alex Yarotsky
• Amit Kapila
• Anand Rao
• Andrew Atkinson
• Ankit Mittal
• Benedict Kofi Amofah
• Bertrand Drouvot
• Brian Brennglass
• Bruce Momjian
• Chris Gooch
• Claire Giordano
• Cody Fincher
• David Wheeler
• Devrim Gündüz
• Divya Bhargov
• Gabriele Bartolini
• Gabriele Fedi
• Gary Evans
• Gayathri Paderla
• Gleb Otochkin
• Greg Potter
• Hari Kiran
• Jelte Fennema-Nio
• Joaquim Oliveira
• John Sly
• Jonathan S. Katz
• Kavach Shah
• Kranthi Kiran Burada
• Makhoul Cassis
• Masahiko Sawada
• Mohamed Ali
• Nazneen Jafri
• Nikunj Doshi
• Payal Singh
• Peter Geoghegan
• Rajni Baliyan
• Raluca Constantin
• Ranjan Burman
• Richard Yen
• Robert Haas
• Robert Treat
• Ryan Booz
• Sehrope Sarkuni
• Selena Flannery
• Shane Borden
• Shayon Sanyal
• Stacey Haysler
• Stephen Brandon
• Sukhpreet Kaur Bedi
• Tatiana Krupenya
• Umair Shahid
• Xavier Fischer

Volunteers:

• Assel Sakenkyzy
• Charlie Lin
• Hengjiali Xu
• Induja Sreekanthan
• Jane Kyung
• Mehboob Alam
• Mingjun Jin
• Mukesh Agrawal
• Omololade Akinleye
• Rinisha Marar
• Selenge Tulga
• Supriya Aggarwal
• Tushar Dahiya
• Valentina Blackledge
• Vanshika Nigam
• Yehonatan Sade

The Women's Breakfast was organized by Stacey Haysler

On 30 September, the Pr

What is Direct I/O, and why would a managed Postgres care about it when taking a backup? Every day, a backup copies your whole database, hundreds of gigabytes, off the same NVMe drives that are answering your queries, and ships it to object storage. Linux treats those reads like any other file read: it keeps a copy of every byte in memory, in the page cache, in case someone asks for it again. Nobody will. To make room for those copies, the kernel throws out data Postgres had in memory and was about to use, and the next query that needs it goes to disk instead.

Direct I/O is the flag that tells the kernel to skip the cache for those reads. Turn it on and a second problem appears. The reads also lose the kernel's readahead, and on a set of four striped NVMe drives a small read keeps one drive busy while the other three sit idle.

The short version A backup reads every byte of a live database off the drives that are serving queries. By default those reads go through the kernel's page cache, pushing out data the database had in memory and costing a kernel copy per byte while queries run. Direct I/O skips the cache. On our test box it left the warm data in place, cut the latency hit queries took during the backup by about two thirds, and used about 14% less CPU. It also switches off readahead, so on striped NVMe the read size and reader count have to match the array. ClickHouse Managed Postgres sizes each direct read to span the whole RAID0 stripe and scales the reader count to the hardware. On a 48 vCPU box with four NVMe drives and a 467 GB database under a live workload, the buffered backup evicted all 40 GiB of a table that was warm in memory and idle. The Direct I/O backups evicted nothing and finished in 71 seconds.

In this post, I walk through integrating JFrog Artifactory with Fujitsu Enterprise Postgres and using Transparent Data Encryption to encrypt the Artifactory metadata stored in the database.

Last week we had our September PostgresEDI meetup, the first since postgres.scot went up as the home for Postgres events in Scotland.

Thursday, September 24th took us back to Paterson's Land at the University of Edinburgh, room 1.27 this time, for two talks that could hardly have come at the subject from further apart. Thanks to everyone who came along, to Daniel for joining us from a different corner of the software world, and to pgEdge for the pizza and refreshments. Special thanks to the friend who came all the way down from Aberdeen for the evening, which is a serious commitment for a Thursday.

The Talks

ColdFront: Transparent PostgreSQL Data Tiering to Apache Iceberg

Jimmy Angelakos (pgEdge)

First up was my own talk on ColdFront, which moves cold rows out of Postgres onto object storage as Apache Iceberg tables in columnar Parquet, and keeps them readable from Postgres as though they had never gone anywhere. The design is deliberately slim: Postgres holds your tables and your SQL, pg_duckdb does the Iceberg reading and writing in-process, Lakekeeper is the catalog, and the object store is whichever one you already have. Your application goes on querying one relation.

The hard part is what happens when the cold tier is writable and several Postgres nodes are writing to it, with a single Iceberg catalog and a single bucket between them. ColdFront takes a ticket before each cold write so that two writers never collide in the first place, and we modelled that protocol in TLA+ rather than trusting our intuition for it.

I closed with vector search over cold data, where a probe comes down to a WHERE clause with no index to build.

📊 View the slides: ColdFront: Transparent PostgreSQL Data Tiering to Apache Iceberg (PDF)

Working with Postgres in Nuxt (including live coding!)

Daniel Roe

After the break, Daniel Roe, who leads the Nuxt core team and works on it full-time at Vercel, showed us what Postgres looks like from the far end of the stack.

He started with wh

Over the past month, several major features got reverted from Postgres 19. At this point, even if everything else goes perfectly, Postgres 19 will be released about a month later than originally planned. A couple recent blog posts seem to suggest the reverts happened due to AI finding complex bugs in those patches, with fixes way too invasive this late in the development cycle. I don’t think that narrative matches reality, and I think it matters to correct that.

Query hints: You asked for it, Postgres 19 gave it to you. Now, they are just waiting to see how you use it.

For years the Postgres community was against adding support for hints. They felt if you had correctly analyzed tables, the Postgres query planner would make the right choice. And they're not wrong, for the most part. Yet many DBAs and developers will tell you of a time when a plan suddenly changed or something was saved by a hint. We can debate the good and bad elements of hints, but the cool thing is that you will soon have a choice in Postgres 19+.

So what are query hints? I came from the SQL Server world like many folks in the Postgres world and they were just there. Oracle, too. They are explicit instructions you give with SQL to change the default execution plan. Note: While industry standard refers to these as "hints," Postgres 19 uses the term "advice," so use both when searching.

This feature, expected later this fall, is coming to Postgres 19 via two new contrib modules (extensions packaged with Postgres that have to be explicitly turned on, like pg_stat_statements, everyone's favorite extension).

• pg_plan_advice - which lets you set query plan advice, like "join order" and "scan type." This also adds a new EXPLAIN option to get the plan advice for any query.
• pg_stash_advice - this lets you save plan advice strings per query id, so if you run the same query over and over (or a parameterized query), it will default to your advice instead of the planner's.

Here's a quick look at what it looks like to turn on plan advice and use it:

Out now on GitHub and PGXN, pg_clickhouse v0.11.0 and the chdb extension v0.1.2 continue our dogged focus on cross-database compatibility. A slew of these enhancements derive from our header-only C libraries, clickhouse-c and pg-clickhouse-c. Let's take a look at just three of the changes in these releases.

What a character {#what_a_character}

First up, character encoding. In the process of developing the benchmark for the chdb extension post, I discovered that pg-clickhouse-c wasn't validating character encodings on text columns. My colleague Philip quickly patched the library to raise an exception when any text- or json-based type contains bytes that violate the database encoding.

This fix shipped in chdb v0.1.1, but we delayed pg_clickhouse a bit to avoid errors for anyone with existing foreign tables that read invalidly-encoded data. pg_clickhouse v0.11.0 adds a new foreign server option, check_encoding, that provides encoding error handlers. The options are:

After trying not to add any Rust packages to the PostgreSQL RPM repository, I finally bit the bullet and pushed pgrx and postgresql_anonymizer to the RPM repos, along with packaging guidelines:

https://github.com/pgdg-packaging/pgdg-rpms/wiki/Packaging-Rust-extensions-(pgrx

Some limitations exist for now:

https://github.com/pgdg-packaging/pgdg-rpms/wiki/Packaging-Rust-extensions-(pgrx)#supported-distributions

Hoping to add RHEL 10.3 and 9.9 support in November.

Enjoy!

In many real production databases, we often see some tables receiving high-frequency updates (millions per day) and autovacuum running repeatedly (hundreds of times per day). Additionally, those tables can sometimes become heavily bloated. The end effect is poor performance, poor concurrency, and an unmanageable database.

In case we are using methods pg_gather for diagnosis, such anomalies are easy to spot by clicking on the table header to sort.

Very often, a closer look at these tables reveals that status-update workloads are driving these heavy updates. Many times, even the table names reveal their purpose through words like “task”, “queue”, or “bucket”. A discussion with application architects often reveals that these tables are used for specific workflows, with status fields tracking what is completed and what remains pending for further processing. There can also be multiple workflow stages. Sounds like use case for Kafka, right? Yes, Kafka is widely used to manage such workflows.

While this is happening on the database side, the buzz around “Just use PostgreSQL” is becoming increasingly popular. System designers and architects want to reduce the complexity of maintaining multiple components and dealing with operational issues. More complexity implies more potential failures. Recently, Chandan Shukla wrote a blog post titled PostgreSQL as a Workflow Engine: Building Reliable Long-Running AI Jobs Without Kafka, detailing trade-offs and considerations for building a simple yet reliable workflow engine using simple methods.

Yet, critical questions remain:

1. Is there a better way to architect database workflows in PostgreSQL?
2. Can we build a highly scalable system without the performance degradation caused by frequent updates and table bloat?
3. Is it possible to eliminate the complexity of external components like Kafka in favor of a purely PostgreSQL-centric workflow engine?

Yes, we can. Furthermore, when building modern enterprise applications where data arrives as even

On 22 September, the Toulouse PUG met, organized by

• Geoffrey Coulaud
• Xavier SIMON
• Jean-Christophe Arnu
• Stéphane Tachoires

Speakers:

• Dimitri Vanoverbeke
• Marc Rechté

On 23 September 2026, the Postgres Meetup Group Valencia met, organized by

• Marcelo Diaz
• Laura Minen
• Martín Marqués

Speakers:

• Heidi Uri
• Javier Aragón Díaz

On 23 September 2026, the Hamburg PostgreSQL User Group met, organized by Joshua Steinmann and Tobias Alvermann.

Speakers:

• Joshua Steinmann
• Tobias Alvermann

On 23 September 2026, the PostgreSQL User Group Vienna met, organized by Cornelia Biacsics and Ranjeet Kumar.

Speakers:

• Laurenz Albe
• Sergey Chehuta

On 24 September 2026, the PostgreSQL Edinburgh Meetup-Group met, organized by Jimmy Angelakos. Daniel Roe delivered a talk.

On 14 September 2026, the Bay Area Postgres Meetup Group met. Organized by Elizabeth Christensen. Elizabeth Christensen and Lukas Fittl delivered a talk.

Since I started building packages separately on each supported RHEL minor version, there has been a repository RPM for each minor version (9.6, 9.7, 9.8, 10.0, ...) in addition to the one for the major versio  (9, 10). All of them share the same package name, and the minor version specific ones are also published in the repository of the latest minor version. As a result, dnf update replaced the major version repository RPM with the one of the latest minor version at that time, which then stayed on that minor version forever, even after the OS moved to a newer one.

I just fixed that issue. Please update the repo RPMs at your earliest convenience. Read the details here:

https://yum.postgresql.org/news/repo-rpms-follow-os-minor-version/

Issue detail: https://github.com/pgdg-packaging/pgdg-rpms/issues/215

I'd like to thank Daryl Herzmann for the report, analysis and testing.

Two years ago I compared pg_repack and pg_squeeze, the two extensions most of us reach for when a table has bloated beyond what autovacuum will ever give back and VACUUM FULL isn't an option.

PostgreSQL 19 changes the starting point. REPACK brings VACUUM FULL and CLUSTER together under one command, and REPACK (CONCURRENTLY) does the rewrite online. It needs no extension and no shared_preload_libraries, so it works on managed services too. That will bring online repacking to a much wider audience, so I spent the last few weeks measuring what it actually does to a running database, and how it compares with the two extensions.

How it works

Rewriting a table is easy when nobody is using it. VACUUM FULL takes an ACCESS EXCLUSIVE lock, copies the live rows into a new file, rebuilds the indexes and swaps the files. Nobody can read or write the table in the meantime, and on a big table that's minutes or hours.

The online version REPACK (CONCURRENTLY) does the same. Except you can use the table while it's being copied and hence it keeps changing while the process runs. A row copied in the first few seconds can get updated two minutes later. Or deleted. An online repack tool needs to do three things.

• Consistent starting point
• Record of everything that changed during the process
• And a way how to apply those changes

REPACK gets the first two steps for free from logical decoding. The mechanism logical replication is using. It starts by creating a temporary replication slot, which gives it a snapshot. Point in time for the initial copy. Because every change that happens during that phase is written to WAL anyway, a background work