Latest Blog Posts

That’s the last post of the series about the talks at the upcoming PG DATA 2026 conference, covering the remaining Friday talks.

Part 1

Part 2

Part 3

First, I wanted to mention two more talks presented by PG DATA organizers: Comparing Apples to Oranges with Postgres’ Type System by Dian Fay and Master Upgrading PostgreSQL, Using Real World stories and examples by Pat Wright. Dian’s talk is about Postgres types, and I can’t say enough how much I love the ability to create new types! Probably even more than I love Postgres extensions! Pat’s talk is about real-life upgrade stories, and although we know way too well that our own upgrades will present us with our unique challenges, it’s still worth learning from other people’s experience

Yet another real-life story is Apoorv Garg’s Electric SQL: Local -first Architecture. Building mobile applications is not something I am familiar with, but it looks like developers had to face familiar problems of reliability, performance, and security, which become especially challenging in the situation of a disappearing network.

Egor Tarasenko’s presentation, Streamlining Data Ingestion and Transformation with Trino + dbt, addresses a well-known problem: handling DDL changes in the source when they are not promptly communicated to the streaming process. I’ve seen multiple solutions to this problem, but none of them appeared to be perfect, so I’m very interested to hear Egor’s perspective.

Several presentations will address understanding and monitoring query execution. First is Alfredo Rodriguez’s presentation How to understand EXPLAIN without dying in the attempt. I remember Alfredo presenting at PG Day Chicago for the first time, and I know he is happy to be back with his by now well-known presentation. Then comes Mohsin Ejaz’s “Why your PostgreSQL tuning guide might be wrong (and what to do about it),” in which he shares DBTune’s perspective. And finally, Postgres plan monitoring and management in practice by Lukas Fittl. I am a great admirer of Lu

I need your feedback to either convince Marketing that I’m a genius and they should put these GitHub Codespaces Walkthroughs on our website, or to tell me I need to keep looking for different ways to make Quickstarts easier.Bi-directional logical replication is not a simple thing. It's a genuinely complicated problem, and getting it right across multiple nodes in a distributed PostgreSQL cluster is hard. That's what makes what we do at pgEdge special: we've done the hard engineering so you don't have to. Multi-master replication, conflict resolution, failover, all of it wrapped up so you can have this capability without needing to be a rocket scientist.But there's still a gap between "this product exists" and "I've actually tried it," and that gap is almost always the setup. You need multiple Postgres instances, a replication extension configured between them, and enough infrastructure to actually prove it's working. By the time you've got all of that running on your laptop, you've burned an afternoon and you haven't learned anything about distributed Postgres yet. You've learned about Docker networking.I wanted to see if I could close that gap. I’ve created three GitHub Codespaces walkthroughs, each targeting a different pgEdge product, each designed to take you from zero to a running environment without installing a single thing on your machine. The issue is that I have no idea whether developers would actually find them useful until I get some data - and that is where you, dear Reader, can help me out, just by trying them and letting me know.

Why Codespaces

Two conferences. Two cities. Two completely different personalities. And me, somewhere in the middle, trying to keep up. 😄

First stop Helsinki, March 24. Nordic PGDay 2026. The Finns are punctual, focused, and deadly serious about PostgreSQL. Talks start on time. Coffee is strong. Silence is not awkward, it is just how things are. I loved every minute of it.

Two days later Paris, March 26. pgDay Paris, the 10th edition! Same elephant, completely different atmosphere. People arrive fashionably late, conversations go long, and somehow everything still works out beautifully. C'est la vie. 

Same community, same passion for open source, but such different energy. If you ever wondered whether PostgreSQL people have a cultural identity — yes, they do. And it depends heavily on latitude. I grabbed my camera to capture both! 😅

The post Nordic Cool Meets Parisian Chic Vlog: Two PGDays, One Week appeared first on CYBERTEC PostgreSQL | Services & Support.

At a couple recent conferences, I got to describe the process Postgres uses to select new committers/maintainers. Usually to users and developers using Postgres, but in some cases it was unclear even to experienced Postgres contributors.

The official docs are rather brief, and don’t explain various important details. Let me explain how I understand the informal process, who’s responsible for what etc.

This post is not meant to give you advice on how to become a committer, that’s a far more subjective question. Perhaps in some future post, not sure yet.

The window for new features in PostgreSQL 19 has closed with the Commitfest PG19-Final on April 9th. 182 patches were committed in this commitfest alone (plus more in the preceding ones). No new features are being accepted for PostgreSQL 20 yet, the git branches for 19 and 20 will likely be branched off in June. Currently the focus of the PostgreSQL community is on stabilizing PostgreSQL 19 so it is ready for release at the end of summer. If everything goes well, it will be released in September 2026.

Time to have a look at what the CYBERTEC people have been doing during the PostgreSQL 19 cycle since the PG 18 branch was split off in June 2025.

The big change: REPACK CONCURRENTLY by Antonin Houska

One of the most popular CYBERTEC open-source PostgreSQL project is pg_squeeze, written by Antonin Houska. Like PostgreSQL's built-in VACUUM FULL feature and other projects like pg_repack, it lets users compact bloated PostgreSQL tables by rewriting them into fresh tables, reclaiming any wasted storage space caused by DELETE and UPDATE operations. The downside of VACUUM FULL is that it requires an access-exclusive lock on tables, so it cannot be used while the database is being accessed by users. In contrast, pg_squeeze and pg_repack perform the operation online. The even support write operations while the table is copied over, duplicating writes to the copy. pg_repack does that the traditional way by creating a set of triggers on the table. CYBERTEC's pg_squeeze uses modern PostgreSQL mechanisms, setting up logical replication between the old and the new table for the duration of the operation. Both methods still need an access-exclusive lock at the end of the operation to swap the new table into the place of the old one, but that is a quick constant-time operation.

Some time ago, PostgreSQL committer Álvaro Herrera approached Antonin asking if CYBERTEC would be willing to donate pg_squeeze for inclusion into PostgreSQL itself. We were of course were happy to support the idea. Antonin and Álvaro put i

Gülçin Yıldırım Jelinek organized the Prague PostgreSQL Meetup on 27 April, 2026 Artjoms Iskovs and Andreas Scherbaum presented at the Meetup.

Cornelia Biacsics organized the PostgreSQL User Group Vienna Meetup #2 on 28th April, 2026. Bernd Reiß and Sahil Sharma spoke at the event.

Sydney PostgreSQL User Group met on April 29, 2026, organized by Rajni Baliyan and Roneel Kumar

Speaker:

• Diksha Sharma
• Roneel Kumar
• Shadab Mohammad

PGDay Armenia happened on April 30 2026, organized by Emma Saroyan and Sarah Conway

Call for Paper Committee:

• Emma Saroyan (Voting Chair)
• Boriss Mejías
• Derk van Veen
• Dian Fay
• Floor Drees
• Gülçin Yıldırım Jelínek
• Ilya Kosmodemiansky
• Laurenz Albe
• Teresa Lopes
• Vik Fearing

Speaker:

• Robert Treat
• Varik Matevosyan
• Xavier Fischer
• Vlada Pogozhelskaya
• Dalto Curvelano
• Vik Fearing
• Ruslan Senchukov
• Alicja Kucharczyk
• Bruce Momjian

Community Blog Posts

• Valeria Kaplan Why sell the idea of contributing to PostgreSQL to your employer

The recent archival of pgBackRest has created an important and necessary conversation in the PostgreSQL community, not only about one project, one maintainer, or one repository, but about how we think about open-source software once it becomes part of critical enterprise infrastructure.

For many PostgreSQL users, pgBackRest has never been just another utility. It has been part of the operational backbone of PostgreSQL environments, especially for backup, restore, archive management, recovery planning, and disaster recovery readiness. The pgBackRest site describes the project as a reliable backup and restore solution for PostgreSQL that can scale to large databases and workloads, which helps explain why many organizations came to rely on it in serious production environments.  

That is why this moment matters, and it is also why the conversation deserves care.

The pgBackRest website now carries a notice of obsolescence stating that pgBackRest is no longer being maintained and asking anyone who forks the project to select a new name. The notice also explains that the project had been a passion project for thirteen years, supported for much of that time by corporate sponsorship, late nights, weekends, and contributions from others in the community.  

When something like this happens, it is natural for people to ask a difficult question: if an open-source project can be archived by its original maintainer, was it truly open source?

My answer is yes, but I think that answer is only the beginning of the conversation.

From a licensing perspective, pgBackRest remains open source. The repository uses the MIT License, which grants broad permission to use, copy, modify, merge, publish, distribute, sublicense, and sell copies of the software, provided the copyright and permission notices are preserved.  

So, legally and structurally, pgBackRest remains open source. The code can be forked, the work can continue, and the community can create a successor if there is enough will, capability, f

This post was originally published on the Microsoft Tech Community Blog.

Introduction

At small scale, using Postgres as a job queue is totally fine, and I’d even say it’s the right call. Fewer moving parts, one less system to manage, ACID guarantees on your jobs. What’s not to love?

The problem is that “small scale” has a ceiling, and the ceiling is lower than most people expect. When you’ve got thousands of concurrent workers hammering a jobs table with SELECT ... FOR UPDATE SKIP LOCKED, things start to behave in ways that aren’t obvious from the application layer. CPU usage creeps up. Also vacuum sometimes can’t keep up. Finally, in the wait event stats, you start seeing ominous entries like LWLock:MultiXactSLRU stacking up across many backends.

This pattern has tripped up teams more than a few times, and it usually plays out the same way: everything works fine in dev and staging, then goes off a cliff in production once the concurrency gets real. So let’s dig into why this happens, and what the alternatives look like.

The Typical Pattern

When using Postgres as a job queue, the standard approach looks something like this:

CREATE TABLE job_queue (
    id         bigserial PRIMARY KEY,
    status     text NOT NULL DEFAULT 'pending',
    payload    jsonb NOT NULL,
    created_at timestamptz NOT NULL DEFAULT now(),
    locked_by  text,
    locked_at  timestamptz
);

CREATE INDEX idx_job_queue_status ON job_queue (status) WHERE status = 'pending';

Workers grab jobs with:

UPDATE job_queue
   SET status = 'processing',
       locked_by = 'worker-42',
       locked_at = now()
 WHERE id = (
     SELECT id FROM job_queue
      WHERE status = 'pending'
      ORDER BY created_at
      LIMIT 1
        FOR UPDATE SKIP LOCKED
 )
 RETURNING *;

And then mark them done:

UPDATE job_queue SET status = 'completed' WHERE id = $1;

Some users may DELETE the row entirely. Either way, the lifecycle is: insert, lock-and-update, update-or-delete. Repeated thousands of times per second

After Part 1 and Part 2, here comes the Friday schedule! I hope that on the second day of the conference, I will have more time to attend different talks and actually stay and listen!

My absolutely-most-anticipated Friday talk is Paul Jungwirth’s Migrating to a Temporal Schema. I hope I do not need to explain why. It has been more than ten years since I first tried to implement an asserted versioning model in Postgres, and I took in all the endless possibilities that opened up when you incorporate time into Postgres. I’ve been closely watching Paul’s work for several years, and in 2024, I asked him to present at the Chicago PostgreSQL User Group. That was a blast, but then I really wanted him to give a talk on temporal tables at any Postgres conference, preferably in Chicago :). I am super-excited that temporal features are making their way into Postgres Core, slowly but surely, and waiting for this talk like for no other!

Another speaker whom I encouraged to apply is Denis Magda. I have been following his work for several years, and I really appreciate his contribution to optimizing applications’ interaction with Postgres. Needless to say, I love his book Just Use Postgres! In fact, the talk that Denis will present at PG DATA is just about that: Using modern Postgres capabilities for hybrid search encourages app developers to use Postgres native capabilities in place of “specialized” third-party tools.

I am also happy that Varun Dhawan’s talk was finally accepted for presentation in Chicago! His talk Using Postgres to locate the best coffee near you! demonstrates the versatility of Postgres and presents some non-trivial use cases.

As much as I love seeing new faces at PG DATA, I really appreciate the well-known speakers who often come to Chicago and consistently provide the highest-quality content to conference attendees. We want to bring the world’s best speakers to our local audience, and I am very grateful to all of those who help us to achieve this goal.

This “Gold standard list” inclu

There's been a kind of persistent myth regarding Postgres since I first started using it seriously over 20 years ago: "Postgres doesn't support user variables." This hasn't really been true since version 8.0 way back in 2005. Part of this stems from the fact it doesn't do things the same way as other common database engines.Why don't we spend a little time exploring the functionality that time forgot?

What Everyone Else Is Doing

Postgres Has Entered the Chat

Continuing my review of the upcoming program for PG DATA 2026, started here.

I will start with Umair’s talk, Securing Multi‑Tenant Databases with Row‑Level Security & Open‑Source Auditing. I always await Umair’s talks with great anticipation because his vision of Postgres is closely aligned with mine, and the topics he discusses are usually the ones I am most interested in. This talk interests me a lot, because the topic of multi-tenancy is the one of my favorite, but Umair’s approach is absolutely the opposite of the path I take, and I wish I had time to discuss and ask the questions afterward! Umair would have to come to Chicago one more time to present at Prairie PUG!

In parallel, Radim Marek will present Visualizing PostgreSQL Storage Internals. I met Radim at DevDays Prague earlier this year, when he talked about regression testing of SQL queries, and to be honest, I was sad that our CfP committee didn’t choose that talk, because it was brilliant. I am sure he will deliver an equally brilliant talk in Chicago (I love what I read in the talk description); it will just be a different one :).

What I really like about this year’s program is that we have many presentations about real-life experiences, about complicated projects that succeded, and lessons learned. On Thursday, we will have a number of such talks. including What I Learned Using PostgreSQL In Real Products by Hajira Sultana and Building and scaling Managed Postgres from 0 to 1000s by Sam Wilson.

Steve Zelasnik is a long-time active Prairie Postgres PUG member (and formerly Chicago PUG member), and he previously presented his work at PG Day Chicago. In his The Multi-Terabyte Trust Exercise: Validating Massive Postgres Migrations presentation, he will share yet another real-life experience and lessons learned. And I am sure, nobody would want to miss Graph-Like Analytics in PostgreSQL for Payer Behavior and Underpayment Detection by Nida Fatima – aren’t we all the victims of this system?!

If you ever participated in one of my op

An Event for Postgres (pronounced /Pō-zet/, and formerly called Citus Con) is a free and virtual developer event. The name POSETTE stands for Postgres Open Source Ecosystem Talks Training & Education.

Features create capability. Calm operations create trust.

Most platform failures do not begin because one feature is missing. They usually begin when teams become afraid to change the systems that run the business.

They become cautious about upgrades, nervous about failover, uncertain about performance changes, and hesitant to touch architecture that has become too important to disturb and too fragile to evolve. Over time, the platform may still function, but it no longer feels safe to improve. That is when technology stops being an accelerator and quietly becomes a constraint.

This is why I believe enterprise PostgreSQL strategy needs a better question.

The question is not only:

Can PostgreSQL support this workload?

In many cases, the answer is already yes.

The more important question is:

Can we operate, evolve, govern, and scale this PostgreSQL platform without creating organizational anxiety?

That is the real enterprise test.

PostgreSQL has become far more than an open source relational database. It is now a serious foundation for transactional systems, cloud-native applications, data platform modernization, analytics-adjacent workloads, extensibility, AI-ready applications, vector search, and governed enterprise architectures. PostgreSQL 18 continues this direction with improvements such as asynchronous I/O, retained optimizer statistics during pg_upgrade, skip scan support for multicolumn B-tree indexes, and uuidv7() for timestamp-ordered UUIDs. These are not just feature bullets. They are signals that PostgreSQL continues to mature as an operational platform, not merely as a database engine.

But features alone do not make a platform enterprise-ready.

Enterprise readiness is not proven in a demo. It is proven during change. It is proven during maintenance windows, failover events, audits, upgrades, performance reviews, scaling pressure, and the uncomfortable Monday morning conversation after something did not behave the way everyone expe