Neues vom PostgreSQL Planet

This post is about what PostgreSQL actually does when you write GRAPH_TABLE syntax. It turns out the database rewrites your graph query into ordinary joins against the underlying tables, then plans them with the regular optimizer. This has three practical consequences you'll notice right away.

A twenty-year-old warning that stays silent on modern PostgreSQL—until it spots a real problem hiding in your connection settings.

On 2 July, 2026, the PostgreSQL Istanbul Meetup met for the first time, organized by Devrim Gündüz, Gülçin Yıldırım Jelínek & Bilge Korkmaz Erdim.

Speakers:

• Viktoriia Hrechukha
• Pavlo Golub

On 2 July 2026, the PostgreSQL User Group Estonia met, organized by Ervin Weber

Speakers:

Actual sunshine ☀️ in Edinburgh 😲 and a room full of Postgres people catching up over pizza: July was good to us. 🐘

TID scans only happen when you explicitly ask for them via `ctid`, making `enable_tidscan` a knob you'll almost certainly never touch.

We at CYBERTEC usually spend a lot of time producing polished community documentaries, but sometimes you just want to push the raw data straight to the output. Welcome to the UNLOGGED experiment for Swiss PgDay 2026!

TL;DR - RegreSQL 1.0 tested that your queries return the right rows. 2.0 tests that they return them the right way, and it does the checking against production's real statistics instead of your empty dev database, which lies.

A migration cleanup dropped an index nobody thought was load-bearing. Every test passed: same rows, same order, green. Three days later the API started timing out on a query that hadn't changed a character, because the planner had quietly switched it from an index scan to a sequential scan over a table that had kept growing.

Disable `enable_sort` to fix a slow sort? Wrong target. Slow sorts need more `work_mem` or better indexes—not this GUC.

I've been going to conferences and meetups of all kinds since 2004. And today — much like in the era when a Nokia brick was giving people their first, still-primitive taste of mobility — these events follow the same format: you give a talk, you answer questions from the room, and the slides get posted somewhere. These days a video lands on YouTube too. Sometimes a chat survives the event, filled mostly with logistics. And that's about it.

 This release was made 9 days ago, but I just realized that I neglected to make a blog post about it. So, for the record, here is the announcement that went out via email. I have released version 21 of the PostgreSQL Buildfarm Client New features

• PatchStack module — a new module for non-standard buildfarms that want to
  test a stack of patches on top of a branch. Note: this module is not for use with the

enable_seqscan does not disable sequential scans. It cannot, and it was never meant to. The documentation says as much: sequential scans cannot be suppressed entirely, because sometimes reading the whole table is the only way to answer the query. What off actually does is tell the planner to avoi…

 Ever have a query 'tossed over the fence' that you find incomprehensible but still have to support it? A few years ago, you would have needed to triage the query. Obfuscated queries can be tough to decipher.  Sometimes, the query is due to someone or an ORM being clever. Many times the query is touch to read because the 

DBeaver recently added its AI Chat to the free, open-source DBeaver Community Edition. And you will find it very at determining what a query does. Let's start with a simple query.

If you've heard one thing about pg_hardstorage, it's probably that "it works against managed PostgreSQL". This post is about the one architectural choice that makes that true, and the consequences that fall out of it.

You are rarely the only thing writing your SQL. Your ORM writes some of it, your nested views write more, and sooner or later one of them joins a table to itself on its own primary key. That join returns exactly the rows it started with. enable_self_join_elimination is the PostgreSQL 18 optimizat…

A PostgreSQL 14 database threw an error that PostgreSQL 14 cannot produce.

A few months ago, I spent time with multiple teams inside the same large financial services organization.

I spoke with the data engineering team. The AI and model team. The platform team. The governance and compliance team.

Each conversation sounded right.

That was the problem.

On 1st of July 2026, Masahiko Sawada committed patch: Add min() and max() aggregate support for uuid.   The uuid type already has a full set of comparison operators and a btree operator class, so it is totally ordered. min() and max() were the only common aggregates missing for it. Add the uuid_larger() and uuid_smaller() … Continue reading "Waiting for PostgreSQL 20 – Add min() and max() aggregate support for uuid."

The Brazilian PostgreSQL community is gearing up for one of the most anticipated events of the year: PGConf.Brasil 2026. Taking place in the city of Blumenau from September 2 - 4, this year’s conference features no less than 13 sessions by EDB colleagues.

enable_presorted_aggregate is on, it has been on since PostgreSQL 16 introduced it, and the single most useful thing you will ever do with it is turn it off for exactly one query. Default on, context user: settable per session, per role, per database, or inline in a single transaction. That last …

One of the most valuable things about partitioned tables is pruning - the database's ability to eliminate entire partitions based on a query predicate. Under conventional wisdom, pruning can only be achieved when querying by the partition key - this makes choosing the right key extremely difficult. However, if your data follows certain patterns, using some clever tricks you can achieve pruning even when filtering by non-partition key columns.