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

I just gave a new presentation at PGDay Armenia titled Building an MCP Server Using Postgres. The talk is a follow-up to my Databases in the AI Trenches talk, and explores how MCP allows functionality beyond LLMs and RAG alone. It includes MCP demos of a radiation detector and pretzel bakery.

How contribution decisions shape the sustainability of the PostgreSQL ecosystem

Last week at PGConf.DE, I gave a talk titled Not Just Altruism: Selling PostgreSQL Contributions to Your Employer.

It didn’t attract a large audience. To be fair, it was right after lunch on the last day of the conference, and there was strong competition from two excellent technical talks. Plus… why bother talking to your employer about contributing to PostgreSQL? :)

The news this week that David Steele, the core maintainer of pgBackRest, one of the most popular backup tools in Postgres ecosystem, is stepping down, highlights a critical point: without ongoing support of contributors from companies in the PostgreSQL ecosystem, and community stewardship of PostgreSQL tooling, the sustainability of both the tools and PostgreSQL itself is at risk.

So what was my talk about?

In short, it was about the motivations, passion, individual sacrifice, and courage of current contributors; the lack of understanding many companies have when it comes to contributing to PostgreSQL (yes, those same companies that rely on PostgreSQL and its ecosystem for their products, services, and revenue); and the minuscule number of contributors compared to PostgreSQL’s ever-growing user base.

A few stats

PostgreSQL has repeatedly been named “DBMS of the Year” by DB-Engines. According to the Stack Overflow survey of nearly 500,000 developers, more than 58% of professional developers have done extensive development work in PostgreSQL over the past year.

So how many people actually contribute to PostgreSQL?

Here’s a rough calculation:

Additionally, there are many individuals who self-report their contributions e.g. those who contribute occasionally or in the short term, volunteer at events, organise meet-ups, review code, members of various Postgres committees and entities, speak about Postgres at non-PG conferences etc. They perform valuable work but are not yet formally recognised.

In the State of PostgreSQL surv

If you are using PostgreSQL in any capacity very likely this week has started for you with a bang. pgBackRest, one of the most known tools for PostgreSQL, praised for the scalable and reliable way to do backups has announced that the project is currently archived.

Archived, you mean EOL?

No! Open source software rarely has a hard “end of life.” What it does have are maintainership gaps and those can be just as serious.

If you are using PostgreSQL in any capacity very likely this week has started for you with a bang. pgBackRest, one of the most known tools for PostgreSQL, praised for the scalable and reliable way to do backups has announced that the project is currently archived.

Archived, you mean EOL?

No! Open source software rarely has a hard “end of life.” What it does have are maintainership gaps and those can be just as serious.

Part 3 of the Semantic Caching in PostgreSQL series. Part 1 covers the fundamentals of  — how it stores query embeddings, runs cosine similarity searches via pgvector, and returns cached LLM results without a round-trip to your model provider. Part 2 goes deeper into production operations: cache tags, eviction policies, monitoring, and Python integration patterns. This post focuses on a specific class of queries that need to be handled differently, and where that handling belongs.A well-tuned semantic cache can deliver 60–80% fewer LLM API calls and matching cost savings. But those numbers depend on caching the right queries. Cache everything and you risk returning answers that were accurate once but are no longer true — and returning them confidently, with no indication that anything is wrong. Understanding the line between cacheable and non-cacheable queries, and owning that line in the right layer of your stack, is what separates a semantic cache that saves money from one that quietly misleads users.

The Two Kinds of Queries Your Cache Will See

I flew 12 hours to Pasadena, survived the sunshine, and came back with a vlog (or pavlog? 🙂) Worth it? Absolutely.

SCALE 23x is one of those events where the hallway conversations are as valuable as the talks. I grabbed my camera and tried to capture some of that energy. Featuring Bruce Momjian, Elizabeth Christensen, Mark Wong, and Gabrielle Roth — people who have been building this community for years.

This is Episode 1 of my conference vlog series. Go watch it. 👇

More episodes coming soon. Stay tuned! 🐘

The post SCALE 23x Vlog: PostgreSQL in Southern California appeared first on CYBERTEC PostgreSQL | Services & Support.

This blog is based on a real production case in which users experienced a serious delay in logical replication. Let me try to explain how to approach similar cases and analyze them in an easy method, because lag in logical replication is a common problem, and we should expect it to come up for different environments. But sometimes troubleshooting can be challenging, especially on DBaaS environments where we won’t get in-depth information at OS / hardware level. Such situations force us to deal with limited information which is available within the PostgreSQL connection (No host-level troubleshooting possible)

The Case

The case that triggered this blog was an attempt to migrate from one cloud vendor, to a recent version of PostgreSQL on a DBaaS offering of another cloud vendor. They started observing huge replication lag and reported to Percona. As usual, we started with pg_gather data collection.

(At Percona, we use pg_gather for diagnosis. Even though this blog and diagnosis refers to pg_gather report, any good diagnosis tool / scripts which can help to study the wait-event pattern and lag details could be able to help)

We saw upto 4.5 terabyte lag is happening at the transmission side (Publisher) on the customer case. The “Transmission”  lag” is the difference between the latest generated LSN and the LSN which the WAL Sender is able to send (sent_lsn of pg_stat_replication). That’s a first indication that the problem is mainly at the publisher side (WAL Sender) and it is not able to send the information fast enough.

Next step of investigation is to understand what both those WAL Senders might be doing. The wait event information for each WAL Sender could provide a clear clue on where the delay is happening.

Both the WAL Senders are mainly waiting in “WalSenderWriteData” event upto 85% of its time. This is a very unusual level of wait.

Following is the logic behind this.

1. Logical decoding hands a finished record to WalSndWriteData()
2. The data is queued in the libpq

An interesting article about PostgreSQL and Open Source.

A very illuminating article about contributing to Open Source and PostgreSQL

Abdelrhman Sersawy wrote an article titled How I started contributing to PostgreSQL in which he describes how he started to write code for the community.

I think the article is very good and detailed, as well as illuminating. It reminds me how I felt the very first times I was pushing commits to the open source ecosystem (not only to PostgreSQL).

A new release of the fast connection pooler for PostgreSQL!

pgagroal 2.1.0 is out!

Yesterday the version 2.1.0 of pgagroal has been released! This is a feature release, and the full changelog is available here.

This release provides a lot of new features, most notably:

• a web console to monitor Prometheus metrics;
• an improved failover support;
• an health check process;
• improve pgagroal-cli ping command output to provide information about the health of the servers;
• improve the test suite;
• a configuration generator;
• a lot of small improvements and a few bug fixing.

Glancing at a few of the above, the improved failover now allows users to define a script that will run after a succesfull failover, so that it is possible to notify all the standbys of the failover. The idea is that, using this notification script, standbys can be reconfigured on the fly to follow a new promoted primary.

The health check process is a new worker process that can be started automatically in background and that will periodically query the configured primary serve to see if it is active. Similarly, it will check the health of the standbys (if any) to ensure they are up and running. The health status (running or down) of the servers is now included also in the pgagroal-cli ping command, so that it can quickly tell the users if both the pooler and the backends are alive.

The startup validation is a way to query the pg_control_system() special function to ensure that the standbys are at the same major version of the primary and warns or even prevent the pooler to start.

The test suite has gone a very important refactoring and improvement, and the coverage has grown providing more confidence in code changes.

A new command, pgagroal-config has been added to the project. This allows users to create a main pgagroal.conf configuration from scratch in an interactive way. Moreover, the same tool can be used to query and modify the configuration file in an automated and repeteable w