Latest Blog Posts

Acknowledged Individuals in the PostgreSQL Release Notes: 2026 Edition
Posted by Mark Wong on 2026-06-05 at 16:36

I shared a chart, in 2022, showing where PostgreSQL contributor gifts are mailed to.  Here's an updated chart (click to zoom in.)

To quickly recap: the PostgreSQL community has been sending gifts to those who contribute directly to a new major release since version 12 came out.  There has now been 6 releases since then and version 19 is slated to be released this fall.

This chart can be construed as a gross indication of where code, testers, reviewers, bug reports, and documentation are coming from.  Thus it is interesting to see things like which countries have the most people, have been growing, or even to just see how many countries are involved with PostgreSQL.

But it's not an exact measure because this is based on the number of people who claim their gift.  Only about half the people in the release notes claim their gift.  It's not very easy to get in touch with everyone.  If you suspect you might be in the release notes or can help someone claim their gift, please take a look at the release notes (links can be found in the documentation or on the community wiki) and reach out to us by e-mail at contributor-gifts <at> postgresql.org to confirm.

Looking Forward to Postgres 19: Query Hints
Posted by Shaun Thomas in pgEdge on 2026-06-05 at 12:02

Well, the world has officially ended. Peter Venkman from Ghostbusters was right all along, and we'll soon be experiencing "human sacrifice, dogs and cats living together, mass hysteria!" Pack it in everybody; we had a great run. The feature freeze of Postgres 19 includes the one feature many claimed would never see the light of day: query hints. I guess "never say never" is pretty good advice.OK, so they're not technically called hints. The Postgres community would never be so pedestrian. Instead, Postgres 19 introduces two new contrib modules: pg_plan_advice and pg_stash_advice. It's "plan advice" you see. Totally different thing.An occasion this monumental deserves a bit more fanfare than simply describing the feature. So let's begin with a walk through one of the longest-running arguments in Postgres history.

A Brief History of "Never"

The Postgres community's position on query hints has been, shall we say, firm. The official wiki page on the subject states it plainly:"We are not interested in implementing hints in the exact ways they are commonly implemented on other databases. Proposals based on "because they've got them" will not be welcomed."Fair enough. The wiki goes on to list six solid reasons hints are problematic:
  • They create maintenance nightmares.
  • They break on upgrades.
  • They discourage root-cause analysis.
  • They scale poorly.
  • The optimizer is usually smarter than you think.
  • They actually
  • planner improvements because users stop reporting bugs.
Yeah, that sounds about right. And for years, that was the end of the discussion. Postgres doesn't do hints. Go fix your statistics. Next topic, please.But behind the scenes, the debate was never quite so settled. Back in late 2010, a legendary thread erupted on the pgsql-performance mailing list that raged on for several months and captured nearly every available sentiment. It started innocuously enough as a complaint about slow queries, veered through Oracle comparisons, and somehow spiraled into a full-blo[...]

All Your GUCs in a Row: data_checksums
Posted by Christophe Pettus in pgExperts on 2026-06-05 at 01:00
A read-only preset, like block_size — SHOW data_checksums tells you whether the cluster has page checksums, and that’s the only interaction the GUC offers. But unlike block_size, this one has a thirteen-year history that’s still being written, and the history is the post. When checksums are on, e…

A Reviewer Was Born
Posted by Lætitia AVROT on 2026-06-05 at 00:00
A friend of mine, Lucas Draescher, submitted his first patch to PostgreSQL back in March. It fixes a file descriptor leak when using io_method=io_uring. The patch is clean, well-motivated, and on its third revision. It has been sitting in the commitfest for two months with zero reviewers. This is not unusual. This is the norm. The PostgreSQL project runs on volunteer time. Committers are brilliant, but there are not many of them and the patch queue is long.

How to test PostgreSQL 19 beta in your Kubernetes cluster
Posted by Floor Drees in CloudNativePG on 2026-06-05 at 00:00
Participate in the PostgreSQL 19 beta program using Kubernetes and our CloudNativePG operator

File Descriptors: The OS Limit That Takes Down PostgreSQL
Posted by warda bibi in Stormatics on 2026-06-04 at 11:12

Most PostgreSQL outages that trace back to file descriptor exhaustion get misread as a database problem. The failure is one layer down: the kernel runs out of file descriptors and PostgreSQL takes the hit. This post covers how that happens under high connection counts, how to read the log sequence when it does, and how to fix it.

What are file descriptors and why PostgreSQL burns through them

In Linux, the kernel represents almost everything as a file descriptor:  TCP sockets, open table files, index files, WAL segments, temp files for sorts and joins, log files. Every open() or accept() call increments a counter. The kernel enforces a system-wide ceiling called fs.file-max. When total FD usage across all processes on the machine hits that ceiling, every new open() fails; regardless of which process is asking.

There’s also a second, separate limit called the per-process ceiling (RLIMIT_NOFILE, controlled by ulimit -n), which caps how many FDs a single process can hold. Either limit can produce the “out of file descriptors” log message or a single backend hitting its per-process ulimit. Both need to be checked during the diagnosis.

PostgreSQL is process-based. Each client connection spawns its own OS process. Each backend holds FDs for its client socket, the table and index files it’s accessing (managed through PostgreSQL’s internal VFD system, capped by max_files_per_process, default 1,000), WAL segments, and any temp files. An idle backend holds 10–15 FDs. An active write backend touching multiple tables with indexes can hold 50–200 or more.

The theoretical worst case is max_connections x max_files_per_process. In practice you won’t hit that ceiling, but even a fraction of it is dangerous when thousands of connections are open at once.

How exhaustion happens

The failure typically follows the same pattern. max_connections is set high, sometimes 10,000 or more, and the application opens connections freely without a pooler. Because each c

[...]

Does pgBackRest work with pg_tde?
Posted by Stefan Fercot in Data Egret on 2026-06-04 at 07:10

Percona Transparent Data Encryption for PostgreSQL (pg_tde) is an open-source PostgreSQL extension that provides Transparent Data Encryption (TDE) to protect data at rest. pg_tde ensures that data stored on disk is encrypted and cannot be read without the proper encryption keys, even if someone gains access to the physical storage media.

A few months ago, Percona published a blog post describing how pgBackRest can be used with encrypted data, although not all features are supported. In that example, they pass decrypted WAL files to the pgBackRest archiving command and state that asynchronous archiving is not supported because (1) it would copy encrypted WAL segments and (2) the restore_command would attempt to re-encrypt the archived WAL files.

Hallway-track discussions at conferences about this limitation gave me the idea to test it myself, as I suspected that pgBackRest could handle encrypted WAL segments transparently. Let’s take a closer look.

Install PostgreSQL and pg_tde

First of all, I’m going to install PostgreSQL and the pg_tde extension on a Debian 12 test server. As pg_tde currently requires a specific PostgreSQL patch to work, the extension is bundled as a component of Percona Server for PostgreSQL. 

sudo apt-get install -y wget gnupg2 curl lsb-release
sudo wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
sudo dpkg -i percona-release_latest.generic_all.deb
sudo apt-get update
sudo percona-release setup ppg-18
sudo apt install percona-postgresql-18
sudo apt-get install -y percona-pg-tde18

There have been many recent discussions about joining efforts to develop a TDE implementation directly in PostgreSQL core, especially during PGConf.dev in Vancouver last month. Until that work is completed, it may be worthwhile to extend PostgreSQL’s capabilities so that extensions like this can run without requiring a patched PostgreSQL fork.

Next, we need to load the library and restart PostgreSQL on our test server: 

ALTER SYSTEM SET shared_preload_librarie
[...]

All Your GUCs in a Row: cursor_tuple_fraction
Posted by Christophe Pettus in pgExperts on 2026-06-04 at 01:00
The planner assumes cursors fetch only 10% of results by default. If you're actually reading them all, that fast-start bias could be killing your performance.

pg_clickhouse 0.3.1: Now With More C
Posted by David Wheeler on 2026-06-03 at 20:13

Hello listeners!

Yesterday, with little fanfare (yay 🎉) we pushed out a minor release to pg_clickhouse, the interface for querying ClickHouse from Postgres. As with previous minor releases, yesterday’s v0.3.0 release requires no reload, restart, or ALTER EXTENSION UPDATE, just reload your session when you’re ready and you’re good to go.

But don’t let the minor version increment deceive you: we made a significant change to pg_clickhouse in this version. What change, you ask? Here it is:

We replaced the clickhouse-cpp library powering the binary driver with the new clickhouse-c library written by my colleague Philip Dubé (a.k.a., serprex). This header-only client library provides a number of substantial benefits vs. the clickhouse-cpp library we previously vendored:

  • Eliminates incompatibility between C++ raise/throw & RAII and Postgres PG_TRY & setjmp/longjmp. The result is much more stable code paths with susceptibility to crashes.
  • Allows us to strictly use Postgres memory contexts, rather than having to deal with both Postgres and C++ allocation patterns, thanks to the library’s support for specifying the memory allocation functions to use.
  • Eliminates the overhead of vendored code, notably absl and cityhash. It does now require liblz4 and libzstd packages, in addition to the previously-required libcurl, uuid, and libssl, but this pattern makes it far more friendly to packager.
  • Far faster compile times and resulting binary. On my M4 MacBook Pro, compiling, installing, and running all the tests now takes around 2 seconds! Meanwhile, the binary size has dropped from 1.8 MB to around 400 KB; on x8664 Linux it went from 4.9 MB to 1.4 MB!

Big change under the hood! Plus a bug fix to properly convert UInt16 values to int32 instead of int16. This is a good one. Get it from the usual suspects:

[...]

Handling graphs with SQL/PGQ in PostgreSQL
Posted by Hans-Juergen Schoenig in Cybertec on 2026-06-03 at 06:51

Starting with version 19 of PostgreSQL users will be able to enjoy something exceptionally useful which will help developers to build even more powerful applications even more quickly. SQL/PGQ — the ISO/IEC 9075-16 (2023) syntax for querying graphs that live in regular relational tables - will be available. This series of posts will explain how this new functionality works and how it can be used to leverage the power of PostgreSQL 19 and beyond.


Your First Graph Query in PostgreSQL 19

The addition introduces two SQL constructs: Namely CREATE PROPERTY GRAPHand GRAPH_TABLE. Let us take a look at the definition of the property graph: 

friends=# \h CREATE PROPERTY GRAPH
Command:     CREATE PROPERTY GRAPH
Description: define a new SQL-property graph
Syntax:
CREATE [ TEMP | TEMPORARY ] PROPERTY GRAPH name
    [ {VERTEX|NODE} TABLES ( vertex_table_definition [, ...] ) ]
    [ {EDGE|RELATIONSHIP} TABLES ( edge_table_definition [, ...] ) ]

where vertex_table_definition is:

    vertex_table_name [ AS alias ] 
[ KEY ( column_name [, ...] ) ] 
[ element_table_label_and_properties ]

and edge_table_definition is:

    edge_table_name [ AS alias ] [ KEY ( column_name [, ...] ) ]
        SOURCE [ KEY ( column_name [, ...] ) 
REFERENCES ] source_table [ ( column_name [, ...] ) ]
        DESTINATION [ KEY ( column_name [, ...] ) 
REFERENCES ] dest_table [ ( column_name [, ...] ) ]
        [ element_table_label_and_properties ]

and element_table_label_and_properties is either:

    NO PROPERTIES | PROPERTIES ALL COLUMNS | PROPERTIES 
( { expression [ AS property_name ] } [, ...] )

or:

   { { LABEL label_name | DEFAULT LABEL } 
[ NO PROPERTIES | PROPERTIES ALL COLUMNS | PROPERTIES 
( { expression [ AS property_name ] } [, ...] ) ] } [...]

URL: https://www.postgresql.org/docs/devel/sql-create-property-graph.html

Before we dig into this in more detail we need to understand what the purpose of all of this is: In a relational database things are stored as tables. What CREATE PROPERTY GRAPH does is to defi

[...]

pg_stat_statements: everything it can't
Posted by Radim Marek on 2026-06-03 at 06:45

Part one made the core case: pg_stat_statements counts, it doesn't record. It walked through how the queryid jumble fragments one logical query into many rows, how the first-seen text freezes your per-request tags, and how the averages bury the p99 that actually pages you. All of that was about data the extension has and distorts.

This part is about the rest: the entries it silently throws away, the query text that can vanish all at once, the plans and replicas it never records, and the knobs that bite. It ends where part one started, with the question the whole investigation was really about: is this the query store Postgres is missing, or just the floor you'd build one on?

The table fills up and evicts your tail

pg_stat_statements.max defaults to 5000. It's a hard cap on entries, set when the server starts (changing it needs a restart, because the hash table is sized in shared memory up front). When the 5001st distinct shape arrives, Postgres doesn't grow the table. It evicts, throwing out the least-executed entries to make room:

If more distinct statements than that are observed, information about the least-executed statements is discarded.

On a healthy app with a few hundred steady shapes, 5000 is plenty and you never think about it. But remember the row explosion from part one. An ORM that splinters one query into hundreds of shapes, or a pre-18 app building dynamic IN lists, can chew through thousands of entries an hour. Once that starts, the view becomes a sliding window over recent noise. Your steady, important queries get evicted to make room for thousands of one-offs, then rebuilt with fresh counters and a fresh first-seen text when they run again. The stats you were trusting reset themselves, and the view never says a word about it.

One place does say something. The companion view pg_stat_statements_info has exactly two columns, and both matter: 

SELECT dealloc, stats_reset FROM pg_stat_statements_info;
 dealloc |          stats_reset
---------+-----------------------
[...]

All Your GUCs in a Row: createrole_self_grant
Posted by Christophe Pettus in pgExperts on 2026-06-03 at 01:00
PostgreSQL 16 overhauled role management to tame the near-superuser power of CREATEROLE.

pg_stat_statements: everything it tells you
Posted by Radim Marek on 2026-06-02 at 20:15

If not first, pg_stat_statements is one of the most used extensions in the PostgreSQL ecosystem. It ships in contrib and costs almost nothing to use. Most of us turn to it to answer the question: what is the database actually doing? It's genuinely useful. You can use it to get a snapshot of what happened in a given timeframe, and make a faster decision about what to fix.

Coming from other database engines, you might reach for it expecting something a bit more, a query store. The built-in feature that keeps normalized queries and their plan history. Except pg_stat_statements is not this. This article is going to deep dive into what the extension really provides.

Because once you lean on it, you might start noticing the rough edges. The gap comes from what "a query store" might come with and what it actually tells you.

The very same query might show up in many separate rows. Discrepancies between what your monitoring says and what mean_exec_time shows. Missing queries. Numbers that changed overnight.

None of that is a bug. It all follows from what pg_stat_statements really is: a fixed-size hash table of running counters, kept in shared memory, keyed by a hash of your parse tree. It counts; it does not record. Hold that one idea in your head and every surprising thing on the list above stops being surprising.

Everything below is reproducible. Paste this into a scratch database: 

CREATE TABLE customers (
    id integer GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name text NOT NULL
);

CREATE TABLE orders (
    id integer GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    customer_id integer NOT NULL REFERENCES customers(id),
    amount numeric(10,2) NOT NULL,
    status text NOT NULL DEFAULT 'pending',
    created_at timestamptz NOT NULL DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO customers (name)
SELECT 'Customer ' || i FROM generate_series(1, 2000) AS i;

INSERT INTO orders (customer_id, amount, status, created_at)
SELECT (random() * 1999 + 1)::int,
       (random() * 500 + 5)::numeric(10,2),
[...]

Hacking Workshop for June/July 2026
Posted by Robert Haas in EDB on 2026-06-02 at 18:36
I was hoping to usual resume the monthly cadence of hacking workshops in June, but it didn't quite happen, largely due to being a little exhausted after pgconf.dev. But, I'm pleased to announce that Melanie Plageman will be joining us to discuss her talk Additional IO Observability in Postgres with pg_stat_io. If you're interesting in joining us, please sign up using this form and I will send you an invite to one of the sessions. As always, thanks to Melanie for joining us.Read more »

Managed Postgres, Examined: Azure Database for PostgreSQL Flexible Server
Posted by Christophe Pettus in pgExperts on 2026-06-02 at 15:00
Azure's managed PostgreSQL differs from competitors by putting the standby in the commit path—every write waits for synchronous replication to a second server…

The Night Our Tables Wouldn’t Stop Growing
Posted by semab tariq in Stormatics on 2026-06-02 at 10:38

We were doing everything right. The migration plan was solid, the team was experienced, and we had done this kind of thing before. But somewhere around midnight, someone on the team noticed something strange. Tables on the destination side were ballooning at an unexpected rate with hundreds of gigabytes being used, while the source side tables sat quietly at just a few megabytes.

Something was very wrong, and we had no idea what.

How It Started

The customer had a PostgreSQL database that they wanted to migrate to a new server. The approach was a logical replication

The initial step in logical replication is the initial table copy. PostgreSQL copies all the existing rows from the source to the destination before replication kicks in and starts streaming live changes. For most tables, this is quick and uneventful.

But when we checked on things the next morning, the picture was not pretty.

What We Saw

On the source side, the tables looked completely normal. Some were 50 GB, some were 90 GB, and a few were just megabytes. Nothing unusual.

On the destination side, the subscriber had a few of those same tables that had grown to over 400 GB each. Overnight. Tables that were 50 to 90GB on the source were now hundreds of gigabytes on the destination, and they were still growing.

What Was Happening

After digging in, we found the culprit. It was statement_timeout.

statement_timeout is a PostgreSQL setting that tells the database, “If any query or operation runs longer than X amount of time, kill it.” It is a sensible safety net. You do not want runaway queries eating resources forever on a production system.

The problem was that on the publisher server, statement_timeout was set to a relatively low value(1 min). And the initial table copy during logical replication setup, which is essentially one big, long-running operat

[...]

When is a function leakproof?
Posted by Laurenz Albe in Cybertec on 2026-06-02 at 05:37

A plumber's advice: I'm not sure about making functions leakproof, but have you tried a few layers of duct tape?
© Laurenz Albe 2026

Instigated by a customer, I've been trying to improve the performance of row-level security. Central to good performance in this area is the concept of leakproof functions and operators. I'll go over the priciples quickly, but I'll focus on the question what leakproof really means, and what it should mean. In a way, this article is a request for comments: I'd be curious what you think about the topic!

Security barrier views and row-level security

PostgreSQL has two related features to hide table rows from a user: Security barrier views and row-level security. The usual reason why you want to hide parts of a table is multi-tenancy: you want to store data belonging to different entities (tenants) in a single table, and you want to prevent any tenant from seeing or manipulating the other tenants' data. You can certainly implement such restrictions in the application code. However, having a ready-made reliable solution inside the database is a good thing.

Security barrier views

This is the older of the two techniques, introduced in PostgreSQL 9.2. It makes use of how PostgreSQL checks the privileges on the objects used by a view: as long as the owner of the view has the permission to access the objects, anybody with privileges on the view can use it. That makes definitions like the following feasible: 

CREATE TABLE account (
   account_nr bigint        PRIMARY KEY,
   owner      text          NOT NULL,
   amount     numeric(15,2) NOT NULL
);

CREATE INDEX account_owner_idx ON account (owner);

CREATE VIEW my_account AS
   SELECT account_nr, owner, amount
   FROM account
   WHERE owner = current_user;

GRANT SELECT, INSERT ON my_account TO PUBLIC;

Using the view, every database role can look at their own account, even though they don't have any privileges on the account table.

Note that I also granted everybody the INSERT privilege on the view. It may surprise some people, but you can also use data modifying statements on views (provided that the view definition is

[...]

All Your GUCs in a Row: cpu_index_tuple_cost, cpu_operator_cost, and cpu_tuple_cost
Posted by Christophe Pettus in pgExperts on 2026-06-02 at 01:00
cpu_tuple_cost, cpu_index_tuple_cost, and cpu_operator_cost are three of the constants the planner uses to price a query, and the single most useful thing to know about all three is that you should almost certainly never change them. The rest of this post is why. PostgreSQL’s planner does not est…

SQL/PGQ in PostgreSQL 19: Graph Queries Without the Graph Database
Posted by Christophe Pettus in pgExperts on 2026-06-01 at 15:00
PostgreSQL 19 adds GRAPH_TABLE, letting you query property graphs with Cypher-like pattern matching over your existing relational tables.

Contributions for week 21, 2026
Posted by Cornelia Biacsics in postgres-contrib.org on 2026-06-01 at 11:35

On May 26 2026, the Bratislava PostgreSQL Meetup came together, organized by Pavlo Golub and Meego Smith. Mayur B. and Devrim Gündüz delivered a presentation.

About 90 attendees showed up for the NYC Postgres meetup that took place May 27 with Gleb Otochkin speaking.

Organizers:

  • Xuan Tang
  • Mason Sharp
  • Mila Zhou
  • Justin Iso
  • Lloyd Massiah

On Thursday, 28 May, the PostgreSQL User Group Vienna met for a casual networking event, organized by Cornelia Biacsics.

On Friday, 29 May 2026 the Ghana PostgreSQL Users Group met for the first virtual meetup, organized by Benedict Kofi Amofah and Ezra Yendau

Community Blog Posts

PGConf.be 2026
Posted by Wim Bertels on 2026-06-01 at 11:07

A round up of the sixth PGConf.be

The shared presentations are online, as are a couple of recordings and turtle-loading have-a-cup-of-tea locally stored photos.

Using the well known and broadly spread technique of inductive reasoning we came to the conclusion that this fifth PGConf.be conference was a success, as well as the art work. No animals or elephants we’re hurt during this event.

The statistics are

  • 75 attendants

    • depending on the session, an extra 200 students attended as well

  • 14 speakers

  • 4 sponsors

This conference wouldn’t have been possible without the help of volunteers.
To conclude a big thank you to all the speakers, sponsors and attendants.
Without them a conference is just a like tee party.

All Your GUCs in a Row: constraint_exclusion
Posted by Christophe Pettus in pgExperts on 2026-06-01 at 01:00
Skip partition scanning with constraint_exclusion, PostgreSQL's old pruning trick.

All Your GUCs in a Row: config_file
Posted by Christophe Pettus in pgExperts on 2026-05-31 at 01:00
PostgreSQL's `config_file` parameter creates a bootstrap paradox: it tells the server where to find its configuration, but lives on the command line only—never…

All Your GUCs in a Row: compute_query_id
Posted by Christophe Pettus in pgExperts on 2026-05-30 at 01:00
PostgreSQL 14 unified query-id computation across all subsystems, but defaulting to always-on would tax every backend.

Open-Source TDE for PostgreSQL: What pg_tde Is, and Whether You Need It
Posted by Christophe Pettus in pgExperts on 2026-05-29 at 15:00
PostgreSQL finally has an open-source Transparent Data Encryption option.

Looking Forward to Postgres 19: The New REPACK Command
Posted by Shaun Thomas in pgEdge on 2026-05-29 at 09:21

Postgres has had a thorn in its paw for a very long time regarding table size. Every modified tuple leaves an old version in the heap for use by older transactions. While  locates these old tuples, it only marks them as reusable rather than returning the space to the OS. Tables only ever grow larger in Postgres.Maybe Postgres 19 can fix that for us.

Options Galore

Historically, the only sanctioned solutions to table bloat have been the VACUUM FULL or CLUSTER commands. Sadly, both of these require an  lock for the entire duration of the operation. In a world where 1TB tables aren't uncommon, it's a ridiculous imposition that's entirely incompatible with a production system.So the community turned to third-party utilities like pg_repack and pg_squeeze, which rewrite tables with minimal locking by leveraging logical decoding under the hood. Some DBAs even run these on a regular schedule to keep tables at their ideal size at all times. But more conservative shops have always been wary of handing table rewrites to a project that operates outside the core engine's safety guarantees. I've personally handled support tickets to repair corruption caused by . While that may have been several years ago, it's enough to induce extra caution rather than reliance.Postgres 19 may prove to change things entirely. The new REPACK command brings this functionality into the core engine itself, complete with a  option that eliminates the prolonged exclusive lock. And as an added bonus,  and  now use the same repack infrastructure internally, so every path to table compaction benefits from the new code.

An Ounce of Prevention

Before we get too excited about our shiny new tool, let's pull back and talk about not needing it. The best repack is the one you never have to run.Postgres ships with autovacuum enabled by default, and for many workloads, the defaults are perfectly fine. For tables with high churn, especially those that see large batch deletes or frequent updates, the defaults tend to be insufficient.The usual fix isn't [...]

PGConf.dev 2026: Our team’s sessions, working groups, and key takeaways
Posted by Floor Drees in EDB on 2026-05-29 at 09:15

Last week, we attended the annual PGConf.dev as a Gold-level sponsor. While most PostgreSQL conferences usually attract users and DBAs, this event draws a strong mix of contributors and community members alike, making it a unique opportunity to get proposals and patches reviewed and to connect across the broader Postgres ecosystem. 

Our team played a major role behind the scenes. Robert Haas helped organize the event, tackling the impressive feat of shaping Tuesday's content across six tracks. Additionally, Jacob Champion served on the Talk Selection Committee, and Phil Alger, Manni Wood

All Your GUCs in a Row: commit_timestamp_buffers
Posted by Christophe Pettus in pgExperts on 2026-05-29 at 01:00
PostgreSQL 17 made SLRU buffer pools configurable for the first time.

Memories from PGConf.dev 2026
Posted by Stefan Fercot in Data Egret on 2026-05-28 at 15:04

Thanks to the organising team, I had the chance to attend PGConf.dev last week in Vancouver, Canada. And luckily, I wasn’t alone there — Valeria could join as well!

This year’s edition was particularly special: we celebrated 30 years of open source PostgreSQL together! Many activities revolved around the anniversary, including a special celebration-themed conference t-shirt, stickers, commemorative posters, and more.

My personal highlight was definitely Wednesday’s round-table retrospective, which brought together project founders and early contributors to reflect on PostgreSQL’s formative years and its remarkable evolution. Featuring Bruce Momjian, Tom Lane, Thomas Lockhart, Jan Wieck, Vadim Mikheev, and Jolly Chen, the discussion revisited what the Postgres project was like in its earliest open source incarnation — technically, culturally, and socially.

Then, on Thursday, a birthday cake cutting ceremony took place following a short speech from Bruce Momjian.

Even though the project still relies on decisions made in its early days — such as hacker mailing-list-focused discussions and documentation written close to the source code using DocBook — it is hard to imagine where PostgreSQL will be 10 or 20 years from now.

Especially today, with AI-assisted content generation accelerating code writing (though not necessarily code review!), the project will inevitably evolve. But as Jan Wieck concluded during the panel, we should take care to preserve and foster the PostgreSQL spirit.

After the panel, a group photo was organised. I can’t wait to see the result!

Speaking of pictures, a photo booth was set up to let attendees take funny pictures celebrating PostgreSQL’s 30th anniversary. As member of the PGDay Lowlands 2026 talk selection committee, I couldn’t resist taking a picture together with Floor Drees, who was the only representative from the organising team attending the event.

This year’s PGConf.dev schedule was divided into three parts.

Tuesda

[...]

Twenty Years, Three CVEs, One AI
Posted by Christophe Pettus in pgExperts on 2026-05-28 at 15:00
Three heap buffer overflows in PostgreSQL — including a 20-year-old pgcrypto bug — were found by an AI code analyzer. But.

Top posters

Number of posts in the past two months

Top teams

Number of posts in the past two months

Feeds

Planet

  • Policy for being listed on Planet PostgreSQL.
  • Add your blog to Planet PostgreSQL.
  • List of all subscribed blogs.
  • Manage your registration.

Contact

Get in touch with the Planet PostgreSQL administrators at planet at postgresql.org.