Latest Blog Posts

Build Your PostgreSQL RBAC Lab

Understanding PostgreSQL roles and privileges becomes much easier when you see them in action.

Instead of simply memorizing GRANT and REVOKE commands, we’ll build a small credit-card application environment and explore how PostgreSQL manages users, object ownership, and access permissions.

What will you learn?

Through this hands-on lab, we’ll explore:

• Roles and Users — Understand LOGIN, NOLOGIN, and why PostgreSQL treats users and groups as roles.
• Object Ownership — Discover how a NOLOGIN role can own databases, schemas, and tables.
• Privileges and Access Control — Learn how database, schema, and table permissions work together.
• Role Membership — Understand INHERIT, SET ROLE, and how privileges flow between roles.
• Least-Privilege Security — Build separate read-only and read-write access for application and reporting users.
• Default Privileges — Automatically configure access for future database objects.

For most of the last decade, every copy of pgAdmin that anyone has ever downloaded was built by a Jenkins server, and for most of that time it did the job perfectly well. It built the Debian and Red Hat packages, the Windows installer, the macOS app bundle, the Python wheel, the container image, the Helm chart and the documentation; it signed them, published them to the download site, and told me when something had gone wrong. It was also, and there is no polite way to put this, a machine (and a bunch of worker machines) that almost nobody could see, running jobs configured through a web interface whose settings existed nowhere else. A handful of us could log into it and push a release, although in practice I was the one who knew how it was wired together and therefore the one who fixed it when it broke, which is its own kind of single point of failure. If you contributed a change to pgAdmin's packaging, you could not read the thing that would build it, and if I had been hit by the proverbial bus, the recovery plan involved somebody logging into a server and reading XML.We have now moved the whole lot to GitHub Actions, and since this changes things for both users and contributors, it seems worth explaining what has changed and why.

Why move at all

We’re wrapping up our series of articles reviewing the changes in PostgreSQL 19. The previous articles covered the first four CommitFests: 2025-07, 2025-09, 2025-11, 2026-01.

Today we begin our review of the March 2026 CommitFest. Why «begin»? As in previous years, the March review is going to be a long one: the final CommitFest of the cycle is where many of the most important changes land. Such a review is hard not only to write but also to read all the way through 🙂. That’s why this time it’s split into four articles.

The first article covers everything related to query optimization, in other words, the topics of our QPT training course. The second will focus on changes more relevant to the DBA1 and DBA2 courses. The third will cover DBA3 and DBS. The fourth will look at new SQL features, as well as changes related to the DEV1 and DEV2 courses.

RevertFest

But first, let’s look at what won’t make it into version 19. An impressive number of features were committed to version 19 before the feature freeze, only to be reverted before the release:

• Partitioning: merging and splitting partitions (3e8bcc864)
• GROUP BY ALL (a32733d8f10)
• pg_dumpall: support for all pg_dump output formats (7ca548f23a6)
• SQL Property Graph Queries (SQL/PGQ) (b1f106c80)
• SQL:2011 Application Time Update & Delete (a4b26b8f7)
• Built-in functions that return the DDL for creating roles, databases, and tablespaces (db169985c)
• Enabling/disabling data checksums without shutting down the cluster (c05d5ce12)

At the time of writing, not all open items have been resolved, and the release is tentatively scheduled for October 29. So the list of new features may shrink further.

CommitFest

With that caveat in mind, let’s move on to the changes related to query optimization. Here’s what’s covered:

• Query plan stabilization and plan advice
• auto_explain: logging EXPLAIN options added by extensions
• EXPLAIN (analyze, timing): reducing timing overhead

This is part 3 of a series about Postgres logical replication use-cases, and about how the feature set has evolved over the past ten years and ten releases (Postgres 10 through the Postgres 19 beta), one architecture at a time. Part 1 built a hub-and-workers system for write scalability and has the table of what each release added, which this post assumes. Part 2 consolidated several application databases into one warehouse. This one is the most common reason to touch logical replication at all: a major-version upgrade with no downtime, and a way back if it goes wrong.

PGConf Asia 2026 is heading to Hong Kong from November 17–18! As a premier regional event for the PostgreSQL community, PGConf.Asia brings together developers, contributors, DBAs, and enterprise users from across the continent. Several EDB team members will be presenting sessions this year. Additionally, EDB's own Bruce Momjian is serving on the organizing committee and co-chairing the program committee. Here is a sneak peek at the EDB-led sessions at PGConf Asia:

Strategic insights

What's Missing in Postgres? - Bruce Momjian (Keynote)

While Postgres introduces roughly 200 features and

PGConf Asia 2026 is heading to Hong Kong from November 17–18! As a premier regional event for the PostgreSQL community, PGConf.Asia brings together developers, contributors, DBAs, and enterprise users from across the continent. Several EDB team members will be presenting sessions this year. Additionally, EDB's own Bruce Momjian is serving on the organizing committee and co-chairing the program committee. Here is a sneak peek at the EDB-led sessions at PGConf Asia:

Strategic insights

What's Missing in Postgres? - Bruce Momjian (Keynote)

While Postgres introduces roughly 200 features and

Do you know about the Winklevoss twins, Cameron and Tyler? They grew up together, went to the same university, and eventually built very different things around technology, finance, and entrepreneurship. Whatever you think of their story, there is something fascinating about twins who start from the same place and then take their abilities into different directions.

Now imagine two twins who grow up in completely different families.

One becomes obsessed with organizing information, while the other becomes obsessed with doing enormous amounts of work at the same time.

They spend years in completely different worlds. Then one day, they meet. And someone says:

“You two might actually work really well together.”

That is the story I want to tell about PostgreSQL and CUDA.

They are not really twins, of course. They were born almost a decade apart, built for different purposes, and live at very different levels of the computing stack.

But there is an uncanny similarity in one of the ideas behind them. 

Let me explain.

Two births, roughly a decade apart

PostgreSQL's story goes back to the POSTGRES project at the University of California, Berkeley. In 1996, the project moved from the name Postgres95 to PostgreSQL, starting with version 6.0.

Then, roughly ten years later, another important piece of the computing world arrived.

In 2006, NVIDIA introduced CUDA, giving developers a programming model for using GPUs for general-purpose computation.

Two technologies with very different beginnings. Relational databases like PostgreSQL have been dealing with something, humans have been struggling with forever:

How do you keep information organized and reliable when lots of people are using it at the same time?

CUDA came from a very different question:

What if we could use the enormous number of computing resources inside a GPU for things other than drawing pixels?

Different questions with different answers.

But there is a common idea hiding underneath both.

A table that shrinks in rows does not shrink on disk. Everyone who has run PostgreSQL for a while knows this in general. I wanted the actual numbers, because "VACUUM reclaims space" means something narrower than it sounds.

Short answer: I deleted every second row of a 2,000,000-row table. The table was 137 MB before, 137 MB after the DELETE, 137 MB after VACUUM, and 68 MB after VACUUM FULL.

Setup

PostgreSQL 18.6, default settings, autovacuum on. 2020 13-inch MacBook Pro, Intel i5-8257U, 8 GB RAM. Sizes are pg_table_size. Times are wall clock for the statement, median of three runs, each on a freshly built table.

Deleting half the rows

The DELETE marks rows dead. VACUUM makes their space reusable, so the next million inserts will fill those gaps instead of growing the file. It does not hand the space back to the operating system, with one exception: empty pages at the very end of the file get cut off. I deleted every second row, so every page kept half its rows and nothing at the end was empty.

VACUUM FULL writes a new copy of the table and drops the old one. That is why it gets the space back, and also why it takes a lock that blocks reads and writes while it runs.

DELETE or TRUNCATE to empty a table

Some advice gets repeated in code review because it sounds like it should matter. I picked four I have seen argued about and measured them. I expected at least two clear winners. I got three ties and one result that went the opposite way from the advice.

Setup

PostgreSQL 18.6, default settings. 2020 13-inch MacBook Pro, Intel i5-8257U, 8 GB RAM. A 2,000,000-row table u with an id, an email, a status and a timestamp. Times are execution times from EXPLAIN (ANALYZE, TIMING OFF), warm cache, first run discarded, median of the rest.

IN, ANY or a VALUES join for 1,000 ids

All three read exactly the same pages. The medians differ, but one IN run took 54 ms and another 15 ms, so I would not read anything into the gap. Use whichever form your driver makes easy. ANY has one practical advantage when the array is passed as a single parameter: the statement text stays the same whatever the number of ids, which is kinder to prepared statements and to pg_stat_statements.

text, smallint or enum for a status column

Three values, two million rows, each stored three ways in its own one-column table.

On 7 October, the London PostgreSQL Meetup group met.

Organizers:

• Valeria Kaplan
• Chris Ellis
• Alastair Turner

Speakers:

• Elizabeth Christensen
• Alex Kasko
• Jimmy Angelakos

On 8 October the PostgreSQL England North Meetup Group. Joseph Bharath Reddy Allam delivered a talk.

Organized by:

• Daniel Chapman
• Stephen Wood
• Kate Gawron
• Peter Schofield

On 8 October, the Greece PostgreSQL Users Group Meetup met. Avinash Vallarapu and Florents Tselai delivered a talk.

Organizers:

• Florents Tselai
• Eftychia Kitsou
• Charis Charalampidi
• Kostas Maistrelis

On 8 October, the Illinois Prairie PostgreSQL User Group met, organized by Henrietta Dombrovskaya and Carlos Aranibar. Devrim Gündüz delivered a talk.

On 9 October, PgPune took place.

Organized by

• Ashish Kumar Mehra
• Sachin D. Kotwal
• Sagar Jadhav
• Rushabh Lathia

Speakers:

• Abhishek Oberoi
• Anuj Sharma
• Ashutosh Sharma
• Debendra Saha
• Deepak Mahato
• Hari Kiran
• Mukund Maheshwari
• Nadeem Khan
• Pushkar Khadilkar
• Sneha Gohil
• Tom Kincaid
• Vishal Sawale