Neues vom PostgreSQL Planet

This is my personal experiment, not an official Apache Cloudberry release.

Since 2017 I have been keeping an eye on the PostgreSQL ecosystem for analytics and data warehousing. At work I had used AWS Redshift, with all the drawbacks and inconveniences a developer gets from a fork of an old PostgreSQL. To my mind, the ideal PostgreSQL-based solution should run on the latest PostgreSQL release, be built as an extension, be easy to start locally in a container for tests, and work with the latest versions of existing extensions such as PostGIS and pgvector.

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!

Errata: the max_connections post told you to size that parameter for “the replication connections.” On 12 and later, don’t. WAL senders have their own seats, sized by this parameter, and have not drawn from max_connections since PostgreSQL 12. The rest of that post stands; that clause is wrong fo…

PostgreSQL 18 ships uuidv7() in core. No extension, no application code. So the old question comes back: if you want UUID keys, does the version matter?

I loaded 5 million rows three ways and measured. Short answer: UUIDv7 inserted in 27 seconds, UUIDv4 in 46. The v4 index came out 29% bigger. Random lookups by key cost the same.

Setup

One table per run:

CREATE TABLE t (id , payload text NOT NULL);

The key was one of:

The SQL standard is written by a committee I sit on, so what people think it ought to contain is a professional interest of mine. The various social media algorithms seem to know this, and they serve me mostly relevant content. This one came via LinkedIn, and here it is in full:

Use PostgreSQL ALTER FUNCTION SET work_mem to stop one function's sorts spilling to disk without a global change. A production fix: 150 GB a day to 0.

The setting I added so my tool could never write to your database turned out to break your app’s writes instead.

The tool is PgLens, a Postgres index advisor I’m building. It only needs to read, so it logs in as a role with no write grants, and it used to start every connection with:

With no shortage of Postgres providers in 2026, one may be confused where to deploy the database powering their next app. One could of course look at dimensions like performance (we do pretty well there), pricing, and extension support. A dimension not as prevalent in the zeitgeist is reliability.

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.

yum.postgresql.org and zypp.postgresql.org have a new look!

Some of you may have seen our pgEdge Starfleet announcement, and be pondering the question of “why?”  Why did we build it, why now, and does the world really need another cloud Postgres service?It's a fair question, and the answer starts where most things at pgEdge start: with our customers.

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

max_sync_workers_per_subscription parallelizes table copies across tables, not within them.

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.

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.

Five indexes, 1,000 tenants, one query, measured in PostgreSQL 17: why tenant_id goes first, what RLS does to the plan, and when partitioning pays off.

Sequence, max()+1, SERIALIZABLE or a counter row: five ways to number invoices per tenant, measured under load in PostgreSQL 17 for duplicates, gaps and speed.

The phrase now appears on almost every technology vendor’s website. That’s exactly why it has stopped meaning much.

A database is called AI-ready because it supports vectors. A cloud platform is AI-ready because it offers foundation models. A data platform is AI-ready because it can build a RAG pipeline. An application platform is AI-ready because somebody added a copilot.

`max_standby_streaming_delay` buys you replication lag, not query time—and when the budget runs out, queries get canceled regardless of how long they've…

Replication slots can silently fill your disk and crash the primary, or you can set `max_slot_wal_keep_size` to kill a stalled replica instead.