Neues vom PostgreSQL Planet

Deleting one tenant from a shared PostgreSQL 17 database, measured: cascade, batches or dropping a partition; locks, batch size, disk space, what stays behind.

count(*) per tenant in PostgreSQL 17, measured: why it got 5× slower for the largest tenant, when estimates are wrong, and what a counter row costs under load.

A trigger-based audit log in PostgreSQL 17, measured: row against statement triggers, full rows against changed columns, and row-level security on the log.

One tenant queues 1,000 jobs, ten others five each: FIFO against round-robin with SKIP LOCKED in PostgreSQL 17, measured, plus a 10-second planner trap.

What an RLS policy costs in PostgreSQL 17: function volatility, the (select …) wrapper, membership subqueries and the leakproof rule that disables your index.

RLS behind PgBouncer in transaction mode, measured: which tenant context leaks, what SET LOCAL does outside a transaction, and one plan shared by tenants.

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+.

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}

`max_wal_size` is a checkpoint trigger, not a maximum—and the real cost is paid by setting it too low, not too high.

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.