Planet PostgreSQL

Hamza Sajawal: pgNow Instant PostgreSQL Performance Diagnostics in Minutes

Tue, 17 Mar 2026 06:53:41 +0000

pgNow is a lightweight PostgreSQL diagnostic tool developed by Redgate that provides quick visibility into database performance without requiring agents or complex setup. It connects directly to a PostgreSQL instance and delivers real-time insights into query workloads, active sessions, index usage, configuration health, and vacuum activity, helping DBAs quickly identify performance bottlenecks. Because it runs as a simple desktop application, pgNow is particularly useful for quick troubleshooting and point-in-time diagnostics when a full monitoring platform is not available.

The tool is currently free to use, and its development is actively maintained by Redgate, with potential future enhancements expected as the project evolves. It analyzes workload behavior using PostgreSQL system views and extensions such as pg_stat_activity and pg_stat_statements.

Prerequisites

Enable pg_stat_statements in PostgreSQL

Most PostgreSQL distributions already include the pg_stat_statements extension. You only need to enable it in shared_preload_libraries and create the extension in the database

Create the extension
CREATE EXTENSION pg_stat_statements;
Verify the Extension

Configure Statement Tracking:

Set the tracking level to capture all statements:

ALTER SYSTEM SET pg_stat_statements.track = 'all';
Reload configurations:
SELECT pg_reload_conf();

Verify the setting:

CREATE USER monitor_user WITH PASSWORD '123#abc';

 -- Grant connection permission

GRANT CONNECT ON DATABASE myoddodb TO monitor_user;

 -- Grant usage on schema (adjust schema name if needed)

GRANT USAGE ON SCHEMA public TO monitor_user;

-- Grant specific table permissions for monitoring

GRANT SELECT ON pg_stat_activity TO monitor_user;

GRANT SELECT ON pg_stat_database TO monitor_user;

GRANT SELECT ON pg_stat_all_tables TO monitor_user;

GRANT SELECT ON pg_stat_user_tables TO monitor_user;

[...]

Bruce Momjian: COMMENT to the MCP Rescue

Mon, 16 Mar 2026 22:15:01 +0000

The COMMENT command has been in Postgres for decades. It allows text descriptions to be attached to almost any database object. During its long history, it was mostly seen as a nice-to-have addition to database schemas, allowing administrators and developers to more easily understand the schema. Tools like pgAdmin allow you to assign and view comments on database objects.

Now, in the AI era, there is something else that needs to understand database schemas — MCP clients. Without database object comments, MCP clients can only use the database schemas, object names, and constraints. With database comments, database users can supply valuable information to allow MCP clients to more effectively match schema objects to user requests and potentially generate better SQL queries. If database users don't want do add such comments, it might be possible for generative AI to create appropriate comments, perhaps by analyzing data in the tables.

Jobin Augustine: What Is in pg_gather Version 33 ?

Mon, 16 Mar 2026 17:03:18 +0000

It started as a humble personal project, few years back. The objective was to convert all my PostgreSQL notes and learning into a automatic diagnostic tool, such that even a new DBA can easily spot the problems. The idea was simple, a simple tool which don’t need any installation but do all possible analysis and […]

Cornelia Biacsics: Contributions for week 10, 2026

Mon, 16 Mar 2026 08:20:47 +0000

On Tuesday March 10, 2026 PUG Belgium met for the March edition, organized by Boriss Mejias and Stefan Fercot.

Speakers:

Esteban Zimanyi
Thijs Lemmens
Yoann La Cancellera

Robert Haas organized a Hacking Workshop on Tuesday March 10, 2026. Tomas Vondra discussed questions about one of his talks.

PostgreSQL Edinburgh meetup Mar 2026 met on Thursday March 12, 2026

Speakers:

Radim Marek
Jimmy Angelakos

FOSSASIA Summit 2026 took place from Sunday March 8 - Tuesday March 10, 2026 in Bangkok.

PostgreSQL speakers:

Koji Annoura
Charly Batista
Gary Evans
Joe Conway
Suraj Kharage
Robert Treat
Sameer Kumar
Roneel Kumar
Sivaprasad Murali
Yugo Nagata
Denis Smirnov
Vaibhav Dalvi
Gyeongseon Park
Bo Peng
Brian McKerr
Chris Travers
Jirayut Nimsaeng
Gilles Darold
Rajni Baliyan

PostgreSQL Conference India took place in Bengaluru (India) from March 11 - March 13, 2026.

Organizers:

Pavan Deolasee
Ashish Kumar Mehra
Nikhil Sontakke
Hari Kiran
Rushabh Lathia

Talk Selection Committee:

Amul Sul
Dilip Kumar
Marc Linster
Thomas Munro
Vigneshwaran c

Speakers:

Abhijeet Rajurkar
Aditya Duvuri
Ajit Awekar
Amit Kumar Singh
Amogh Bharadwaj
Amul Sul
Andreas Scherbaum
Ashutosh Bapat
Avinash Vallarapu
Boopathi Parameswaran
Claire Giordano
Danish Khan
Deepak R Mahto
Dilip Kumar
Divya Bhargov
Dr. M. J. Shankar Raman
Franck Pachot
Hari Kiran
Hari Prasad
Harish Perumal
Jayant Haritsa
Jim Mlodgenski
Jobin Augustine
Joe Conway
Kanthanathan S
Kevin Biju
Koji Annoura
Kranthi Kiran Burada
Lalit Choudhary
Michael Zhilin
Mithun Chicklore Yogendra
Mohit Agarwal
NarendraSingh Tawar
Neel Patel
Neeta Goel
Nikhil Chawla
Nikhil Sontakke
Nishad Mankar
Palak

[...]

Richard Yen: Learning AI Fast with pgEdge's RAG

Mon, 16 Mar 2026 08:00:00 +0000

Introduction

If you’ve been paying attention to the technology landscape recently, you’ve probably noticed that AI is everywhere. New frameworks, new terminology, and a dizzying array of acronyms and jargon: LLM, RAG, embeddings, vector databases, MCP, and more.

Honestly, it’s been difficult to figure out where to start. Many tutorials either dive deep into machine learning theory (Bayesian transforms?) or hide everything behind a single API call to a hosted model. Neither approach really explains how these systems actually work.

Recently I spent some time experimenting with the pgEdge AI tooling after hearing Shaun Thomas’ talk at a PrairiePostgres meetup. He talked about how to set up the various components of an AI chatbot system, starting from ingesting documents into a Postgres database, vectorizing the text, setting up a RAG and then an MCP server.

When I got home I wanted to try it out for myself – props to the pgEdge team for making it all free an open-source! What surprised me most was not just that everything worked, but how easy it was to get a complete AI retrieval pipeline running locally. More importantly, it turned out to be one of the clearest ways I’ve found to understand how modern AI systems are constructed behind the scenes. Thanks so much, Shaun!

The pgEdge AI Components

The pgEdge AI ecosystem provides several small tools that fit together naturally. I’ll go through them real quickly here

Doc Converter – The doc-converter normalizes documents into a format that is easy to process downstream. Whether the input is PDF, HTML, Markdown, or plain text, the converter produces clean text output suitable for ingestion.
Vectorizer – The vectorizer handles the process of converting text chunks into embeddings. These embeddings are numeric representations of text that capture semantic meaning. Once generated, they can be stored inside PostgreSQL using pgvector and queried with similarity search.
Retrieval-Augmented Generation (RAG) Server – The R

[...]

Dave Page: AI Features in pgAdmin: AI Insights for EXPLAIN Plans

Mon, 16 Mar 2026 06:31:22 +0000

This is the third and final post in a series covering the new AI functionality in pgAdmin 4. In the first post, I covered LLM configuration and the AI-powered analysis reports, and in the second, I introduced the AI Chat agent for natural language SQL generation. In this post, I'll walk through the AI Insights feature, which brings LLM-powered analysis to PostgreSQL EXPLAIN plans.Anyone who has spent time optimising PostgreSQL queries knows that reading EXPLAIN output is something of an acquired skill. pgAdmin has long provided a graphical EXPLAIN viewer that makes the plan tree easier to navigate, along with analysis and statistics tabs that surface key metrics, but interpreting what you're seeing and deciding what to do about it still requires a solid understanding of the query planner's behaviour. The AI Insights feature aims to bridge that gap by providing an expert-level analysis of your query plans, complete with actionable recommendations.

Where to Find It

AI Insights appears as a fourth tab in the EXPLAIN results panel, alongside the existing Graphical, Analysis, and Statistics tabs. It's only visible when an LLM provider has been configured, so if you don't see it, check that you've set up a provider in Preferences (as described in the first post). The tab header simply reads 'AI Insights'.To use it, run a query with EXPLAIN (or EXPLAIN ANALYZE for the most useful results, since actual execution timings give the AI much more to work with), and then click on the AI Insights tab. The analysis starts automatically when you switch to the tab, or you can trigger it manually with the Analyze button.

What the Analysis Provides

The AI Insights analysis produces three sections:

Summary

A concise paragraph providing an overall assessment of the query plan's performance characteristics. This gives you a quick sense of whether the plan is generally healthy or has significant issues worth investigating. For well-optimised queries, the summary will confirm that the plan looks reasonable; for problematic o[...]

Pavel Luzanov: PostgreSQL 19: part 4 or CommitFest 2026-01

Mon, 16 Mar 2026 00:00:00 +0000

Continuing the series of CommitFest 19 reviews, today we’re covering the January 2026 CommitFest.

The highlights from previous CommitFests are available here: 2025-07, 2025-09, 2025-11.

Partitioning: merging and splitting partitions
pg_dump[all]/pg_restore: dumping and restoring extended statistics
file_fdw: skipping initial rows
Logical replication: enabling and disabling WAL logical decoding without server restart
Monitoring logical replication slot synchronization delays
pg_available_extensions shows extension installation directories
New function pg_get_multixact_stats: multixact usage statistics
Improvements to vacuum and analyze progress monitoring
Vacuum: memory usage information
vacuumdb --dry-run
jsonb_agg optimization
LISTEN/NOTIFY optimization
ICU: character conversion function optimization
The parameter standard_conforming_strings can no longer be disabled

...

Ashutosh Bapat: Professional karma

Sat, 14 Mar 2026 05:48:00 +0000

In the very early days of my career, an incident made me realise that perfoming my job irresponsibily will affect me adversely, not because it will affect my position adversely, but because it can affect my life otherwise also. I was part a team that produced a software used by a financial institution where I held my account. A bug in the software caused a failure which made several accounts, including my bank account, inaccessible! Fortunately I wasn't the one who introduced that bug and neither was other software engineer working on the product. It has simply crept through the cracks that the age-old software had developed as it went through many improvements. Something that happens to all the architectures, software or otherwise in the world. That was an enlightening and eve opening experience. But professional karma is not always bad; many times it's good. When the humble work I do for earning my living also improves my living, it gives me immense satisfaction. It means that it's also improving billions of lives that way across the globe.

When I was studying post-graduation in IIT Bombay, I often travelled by train - local and intercity. The online ticketing system for long distant trains was still in its early stages. Local train tickets were still issued at stations and getting one required standing in a long queue. Fast forward to today, you can buy a local train ticket on a mobile App or at a kiosk at the station by paying online through UPI. In my recent trip to IIT Bombay I bought such a ticket using GPay in a few seconds. And know what, UPI uses PostgreSQL as an OLTP database in its system. I didn't have to go through the same experience thank to the same education and the work I am doing. Students studying in my alma-matter no more have to go through the same painful experience now, thanks to many PostgreSQL contributors who once were students and might have similar painful experiences in their own lives.

In PGConf.India, Koji Annoura, who is a Graph database expert talked about o

[...]

Shane Borden: More Obscure Things That Make It Go “Vacuum” in PostgreSQL

Fri, 13 Mar 2026 15:51:40 +0000

I previously blogged about ensuring that the “ON CONFLICT” directive is used in order to avoid vacuum from having to do additional work. I also later demonstrated the characteristics of how the use of the MERGE statement will accomplish the same thing.

You can read the original blogs here Reduce Vacuum by Using “ON CONFLICT” Directive and here Follow-Up: Reduce Vacuum by Using “ON CONFLICT” Directive

Now in another recent customer case, I was chasing down why the application was invoking 10s of thousands of Foreign Key and Constraint violations per day and I began to wonder, if these kinds of errors also caused additional vacuum as described in those previous blogs. Sure enough it DEPENDS.

Let’s set up a quick test to demonstrate:

/* Create related tables: */
CREATE TABLE public.uuid_product_value (
        id int PRIMARY KEY,
        pkid text,
        value numeric,
        product_id int,
        effective_date timestamp(3)
        );

CREATE TABLE public.uuid_product (
        product_id int PRIMARY KEY
        );

ALTER TABLE uuid_product_value
    ADD CONSTRAINT uuid_product_value_product_id_fk 
    FOREIGN KEY (product_id) 
    REFERENCES uuid_product (product_id) ON DELETE CASCADE;

/* Insert some mocked up data */
INSERT INTO public.uuid_product VALUES ( 
        generate_series(0,200));

INSERT INTO public.uuid_product_value VALUES ( 
        generate_series(0,10000), 
        gen_random_uuid()::text,
        random()*1000,
        ROUND(random()*100),
        current_timestamp(3));
 
/* Vacuum Analyze Both tables */
VACUUM (VERBOSE, ANALYZE) uuid_product;
VACUUM (VERBOSE, ANALYZE) uuid_product_value;

/* Verify that there are no dead tuples: */
SELECT
    schemaname,
    relname,
    n_live_tup,
    n_dead_tup
FROM
    pg_stat_all_tables
WHERE
    relname in ('uuid_product_value', 'uuid_product');
 
 schemaname |      relname       | n_live_tup | n_dead_tup
------------+--------------------+------------+------------
 public     | uuid_product_value |      10001 |          0
 public

[...]

Shaun Thomas: Using Patroni to Build a Highly Available Postgres Cluster—Part 2: Postgres and Patroni

Fri, 13 Mar 2026 06:12:14 +0000

Welcome to Part two of our series about building a High Availability Postgres cluster using Patroni! Part one focused entirely on establishing the DCS using etcd, providing the critical layer that Patroni uses to store metadata and guarantee its leadership token uniqueness across the cluster.With this solid foundation, it's now time to build the next layer in our stack: Patroni itself. Patroni does the job of managing the Postgres service and provides a command interface for node administration and monitoring. Technically the Patroni cluster is complete at the end of this article, but stick around for part three where we add the routing layer that brings everything together.Hopefully you still have the three VMs where you installed etcd. Those will be the same place where everything else happens, so if you haven’t already gone through the steps in part one, come back when you’re ready.Otherwise, let’s get started!

Installing Postgres

The Postgres community site has an incredibly thorough page dedicated to installation on various platforms. For the sake of convenience, this guide includes a simplified version of the Debian instructions. Perform these steps on all three servers.Start by setting up the PGDG repository:Then install your favorite version of Postgres. For the purposes of this guide, we’re also going to stop Postgres and drop the initial cluster the Postgres package creates. Patroni will recreate all of this anyway, and it should be in control.It’s also important to completely disable the default Postgres service since Patroni will be in charge:Finally, install the version of Patroni included in the PGDG repositories. This should be available on supported platforms like Debian and RedHat variants, but if it isn’t, you may have to resort to the official installation instructions.Once that command completes, we should have three fresh VMs ready for configuration.

Configuring Patroni the easy way

The Debian Patroni package provides a tool called that transforms a Patroni template into a configur[...]

Deepak Mahto: PGConf India 2026: PostgreSQL Query Tuning: A Foundation Every Database Developer Should Build

Fri, 13 Mar 2026 01:12:23 +0000

Most PostgreSQL tuning advice that folks chase is quick fixes but not on understanding what made planners choose an path or join over others optimal path. !

Tuning should not start with Analyze on tables involved in the Query but with intend what is causing the issue and why planner is not self sufficient to choose the optimal path.

Most fixes we search for SQL tuning are around,

Add an index. 
Rewrite the query. 
Bump work_mem. 
Done.

Except it’s not done. The same problem comes back, different query, different table, same confusion.

The Real Problem

A slow query is a symptom. Statistics, DDL, query style, and PG version are the actual culprit’s.

Before you touch anything, you need to answer five questions — in order:

Find it — which query actually hurts the most right now?
Read the plan — what is the planner doing and where is it wrong?
Check statistics — is the planner even working with accurate data?
Check the DDL — is your schema helping or hiding the answer?
Check GUCs & version — are the defaults silently working against you?

5-Dimension SQL Tuning Framework

Most developers skip straight to question two. Many skip to indexes without asking any question at all.

What I Covered at PGConf India 2026

I presented this framework at PGConf India yesterday, a room full of developers and DBA , sharp questions, and a lot of “I’ve hit exactly this” moments.

The slides cover core foundations for approaching Query Tuning and production gotchas including partition pruning, SARGability, CTE fences, and correlated column statistics.

Slide – PostgreSQL Query Tuning: A Foundation Every Database Developer Should Build

Pavel Luzanov: PostgreSQL 19: part 3 or CommitFest 2025-11

Fri, 13 Mar 2026 00:00:00 +0000

This article reviews the November 2025 CommitFest.

For the highlights of the previous two CommitFests, check out our last posts: 2025-07, 2025-09.

Planner: eager aggregation
Converting COUNT(1) and COUNT(not_null_col) to COUNT(*)
Parallel TID Range Scan
COPY … TO with partitioned tables
New function error_on_null
Planner support functions for optimizing set-returning functions (SRF)
SQL-standard style functions with temporary objects
BRIN indexes: using the read stream interface for vacuuming
WAIT FOR: waiting for synchronization between replica and primary
Logical replication of sequences
pg_stat_replication_slots: a counter for memory limit exceeds during logical decoding
pg_buffercache: buffer distribution across OS pages
pg_buffercache: marking buffers as dirty
Statistics reset time for individual relations and functions
Monitoring the volume of full page images written to WAL
New parameter log_autoanalyze_min_duration
psql: search path in the prompt
psql: displaying boolean values
pg_rewind: skip copying WAL segments already present on the target server
pgbench: continue running after SQL command errors

...

Vibhor Kumar: Transparent Column Encryption in PostgreSQL: Security Without Changing Your SQL

Thu, 12 Mar 2026 15:19:49 +0000

There is a moment in many database reviews when the room becomes a little too quiet.

Someone asks:

“Which columns in this database are encrypted?”

At first, the answers sound reassuring.

“We use TLS.”

“The disks are encrypted.”

“The application handles sensitive fields.”

And then the real picture starts to emerge.

Some values are encrypted in one service but not another.

Some migrations remembered to apply encryption.

Some scripts did not.

Some backups are safe in theory, but no one wants to test that theory the hard way.

That is the uncomfortable truth of database security:

encryption is often present, but not always enforced where the data actually lives.

That is exactly the problem I wanted to explore with the PostgreSQL extension:

column_encrypt: https://github.com/vibhorkum/column_encrypt

This extension provides transparent column-level encryption using custom PostgreSQL datatypes so developers can read and write encrypted columns without changing their SQL queries.

And perhaps the most human part of this project is this:

the idea for this project started back in 2016.

It stayed with me for years as one of those engineering ideas that never quite leaves your mind — the thought that PostgreSQL itself could enforce encryption at the column level.

Now I’ve finally decided to release it.

This is the first public version. It’s a starting point — useful, practical, and hopefully something the PostgreSQL community can explore and build upon.

Why This Matters

Encryption conversations often focus first on infrastructure.

We encrypt disks.
We use TLS connections.
We protect credentials.

All of these are important.

But once data is inside the database, a different question matters:

What happens if someone gains access to the database itself?

That access might come from:

a leaked backup
an overprivileged account
a dump file
a compromised service
an operational mista

[...]

Richard Yen: Debugging RDS Proxy Pinning: How a Hidden JIT Toggle Created Thousands of Pinned Connections

Thu, 12 Mar 2026 08:00:00 +0000

Introduction

When using AWS RDS Proxy, the goal is to achieve connection multiplexing – many client connections share a much smaller pool of backend PostgreSQL connections, givng more resources per connection and keeping query execution running smoothly.

However, if the proxy detects that a session has changed internal state in a way it cannot safely track, it pins the client connection to a specific backend connection. Once pinned, that connection can never be multiplexed again. This was the case with a recent database I worked on.

In this case, we observed the following:

extremely high CPU usage
relatively high LWLock wait times
OOM killer activity on the database, maybe once every day or two
thousands of active connections

What was strange about it all was that the queries involved were relatively simple, with max just one join.

Finding the Pinning Source

To get to the root cause, one option was to look in pg_stat_statements. However, that approach had two problems:

Getting a clean snapshot of the statistics while thousands of queries were being actively processed would be tricky.
pg_stat_statements normalizes queries and does not expose the values passed to parameter placeholders.

Instead, to see the actual parameters, we briefly enabled log_statement = 'all'. This immediately surfaced something interesting in the logs, which could be downloaded and reviewed on my own time and pace.

What we saw were statements like SELECT set_config($2,$1,$3) with parameters related to JIT configuration – that was the first real clue.

Getting to the Bottom

After tracing the behavior through the stack, the root cause turned out to be surprisingly indirect. The application created new connections through SQLAlchemy’s asyncpg dialect, and we needed to drill down into that driver’s behavior.

Step 1 – Reviewing how SQLAlchemy registers JSON codecs

During connection initialization, SQLAlchemy runs an on_connect hook:

def connect(conn):

[...]

gabrielle roth: SCaLE23x

Thu, 12 Mar 2026 00:38:49 +0000

I’m back from Pasadena after SCaLE23x and another installment of PostgreSQL@SCaLE! It was really just wonderful this year, seeing old friends and making new ones, talking to people and soaking up knowledge. I’m looking forward to implementing what I learned. Expo Hall:We had a lot of booth volunteers this year. Thank you all so much; […]

Bruce Momjian: The MySQL Shadow

Wed, 11 Mar 2026 14:15:02 +0000

For much of Postgres's history, it has lived in the shadow of other relational systems, and for a time even in the shadow of NoSQL systems. Those shadows have faded, but it is helpful to reflect on this outcome.

On the proprietary side, most database products are now in maintenance mode. The only database to be consistently compared to Postgres was Oracle. Long-term, Oracle was never going to be able to compete against an open source development team, just like Sun's Solaris wasn't able to compete against open source Linux. Few people would choose Oracle's database today, so it is effectively in legacy mode. The Oracle shadow is clearly fading. In fact, almost all enterprise infrastructure software is open source today.

The MySQL shadow is more complex. MySQL is not proprietary, since it is distributed as open source, so it had the potential to ride the open source wave into the enterprise, and it clearly did from the mid-1990s to the mid-2000s. However, something changed, and MySQL has been in steady decline for decades. Looking back, people want to ascribe a reason for the decline:

Sun buying MySQL AB
Oracle buying Sun
Poor stewardship of MySQL by Oracle, including recent layoffs

Vibhor Kumar: Beyond Features: What a PostgreSQL Strategy Discussion Taught Me About Calm, Modern Platforms

Wed, 11 Mar 2026 13:36:44 +0000

Last December, I was part of a long enterprise discussion centered on PostgreSQL.

On paper, it looked familiar: a new major release, high availability and scale, Aurora migration, monitoring, operational tooling, and the growing conversation around AI-assisted operations.

The usual ingredients were all there.

But somewhere in the middle of that day, the tone of the room changed.

It did not change when we talked about new PostgreSQL capabilities. It changed when the conversation moved to upgrades, patching, monitoring quality, and operational control.

That was the moment I realized this was not really a feature discussion.

It was a trust discussion.

Not trust in PostgreSQL as a database. That question is mostly behind us.

It was trust in something more practical: can this platform evolve without exhausting the team responsible for it? Can it scale without becoming harder to reason about? Can it be upgraded without becoming a quarterly trauma ritual? Can it be monitored without operators drowning in false signals? Can it support modernization without making every change feel dangerous?

That, to me, is where the PostgreSQL conversation has matured.

A modern PostgreSQL platform is not defined only by what it can do. It is defined by how calmly it can change.

Why this matters now

This matters because PostgreSQL is no longer entering the enterprise through side doors. In many organizations, it is already trusted with serious workloads and is increasingly central to modernization plans.

That changes the questions.

A few years ago, teams often asked whether PostgreSQL was ready for enterprise use. Today, the better question is whether the operating model around PostgreSQL is ready for enterprise reality.

Because the database can be strong while the surrounding practice is weak.

That is where many teams struggle. They like PostgreSQL, but lag on upgrades. They have HA designs, but unclear failure playbooks. They have monitoring, but poor signal qualit

[...]

Floor Drees: The Future of Postgres on the agenda: EDB’s PGConf.dev Preview

Wed, 11 Mar 2026 12:29:11 +0000

PGConf.dev is heading to Vancouver, Canada, from May 19–22, bringing together the users, developers, and community organizers driving the future of PostgreSQL. EDB is proud to be a Gold-level sponsor this year, with our own Robert Haas serving as an organizer and Jacob Champion contributing to the Program Committee. Following a highly successful Call for Papers, we’ve put together this preview of the EDB-led sessions you won't want to miss.

Lukas Fittl: The Dilemma of the ‘AI DBA’

Wed, 11 Mar 2026 00:00:00 +0000

Like many in the industry, my perspective on AI tools has shifted considerably over the past year, specifically when it comes to software engineering tasks. Going from “this is nice, but doesn’t really solve complex tasks for me” to “this actually works pretty well for certain use cases.” But the more capable these tools become, the sharper one dilemma gets: you can hand off the work, but an AI agent won’t ultimately be responsible when the database goes down and your app stops working. For…

Lætitia AVROT: work_mem: it's a trap!

Wed, 11 Mar 2026 00:00:00 +0000

My friend Henrietta Dombrovskaya pinged me on Telegram. Her production cluster had just been killed by the OOM killer after eating 2 TB of RAM. work_mem was set to 2 MB. Something didn’t add up. Hetty, like me, likes playing with monster hardware. 2 TB of RAM is not unusual in her world. But losing the whole cluster to a single query during peak operations is a very different kind of problem from a 3am outage.

Virender Singla: The Part of PostgreSQL We Discuss the Most — 2

Tue, 10 Mar 2026 17:27:35 +0000

PostgreSQL and Oracle Implementation

In the Part 1, we explored the general concepts of MVCC and the implications of storing data snapshots either out-of-place or within heap storage, we can now map these methodologies to specific database engines.

The PostgreSQL MVCC implementation aligns with the DatabaseI model, whereas Oracle and MySQL are closely related to the DatabaseO model. Specifically, Oracle utilizes block versioning and stores older versions in a separate storage area known as UNDO, while PostgreSQL employs row versioning.

These engines further optimize their respective in-place or out-of-place MVCC strategies:

Oracle (DatabaseO) Delta Storage: To improve efficiency, Oracle avoids copying an entire block to UNDO. Instead, it only stores the modified columns as a “delta.” Consequently, when a query requires an older image, the engine applies this delta to the current heap block to reconstruct the previous state.
PostgreSQL (DatabaseI) Visibility Map (VM): To mitigate the overhead of scanning the entire heap for garbage collection, PostgreSQL uses a Visibility Map. This data structure maintains per-block information of heap, allowing the garbage collector to identify specific blocks containing garbage instead of performing a full table scan.
Heap Only Tuple (HOT) Optimization: PostgreSQL addresses continuous index churn caused by new physical address (ctid) through HOT optimization. If a new row version fits within the same block as the previous version, the indexes are not updated. Instead, index access lands on the heap block, accessing the old version, which then chains directly to the new version within the same block. Note that it’s still a single block fetch.
Row Locking Mechanism: PostgreSQL utilizes the visibility counters to manage row locking as well, whereas Oracle employs a distinct data structure located in the block header for this purpose.
Handling Multiple Data Versions: When a row undergoes multiple updates, Oracle maintai

[...]

Virender Singla: The Part of PostgreSQL We Discuss the Most — 1

Tue, 10 Mar 2026 17:26:58 +0000

Early in my PostgreSQL journey, I often sensed that a conversation between two Postgres professionals inevitably revolves around vacuuming. That lighthearted observation still remains relevant, as my LinkedIn feeds are often filled with discussions around vacuuming and comparing PostgreSQL’s Multi-Version Concurrency Control (MVCC) implementation to other engines like Oracle or MySQL. Given that people are naturally drawn to the most complex components of a system, I will continue this journey by exploring a detailed comparison of these database architectures focused on the MVCC implementations.

What is MVCC?

Stone age databases relied on strict locking mechanisms to handle concurrency, which proved inefficient under heavy load. In these traditional models, a read operation required a shared lock that prevented other transactions from updating the record. Conversely, write operations required exclusive locks that blocked incoming reads. This resulted in significant lock contention, where readers blocked writers and writers blocked readers.

To solve this, RDBMS implemented MVCC. The idea was very simple. Rather than overwriting data immediately, maintain multiple versions of data simultaneously. This allows transactions to view a consistent snapshot of the database as it existed at a specific point in time. For instance, if User 1 starts reading a table just before User 2 starts modifying a record, User 1 sees the original version of the data without hindering User 2’s progress. Without MVCC, the system would be forced to either serialize all access — making User 2 wait — or risk data consistency anomalies like dirty or non-repeatable reads where User 1 sees uncommitted changes that might eventually be rolled back.

Database engines utilize various architectures to manage this data versioning. A particularly notable point of discussion is the comparison between “in-place” and “out-of-place” data versioning techniques. Let’s examine these approaches more closely.

Explaining In-Place and Out-of

[...]

Floor Drees: Shaping SQL in São Paulo

Tue, 10 Mar 2026 13:37:56 +0000

Last week, EDB engineers Matheus Alcantara and Euler Taveira attended the ISO/IEC SQL Standards Committee meeting in São Paulo as invited guests, supported remotely by veteran member Peter Eisentraut. The duo compared the collaborative environment to a PostgreSQL "Commitfest," where technical papers are proposed, debated, and refined much like code patches.

Andrew Dunstan: Validating the shape of your JSON data

Tue, 10 Mar 2026 10:13:17 +0000

One of the great things about PostgreSQL's jsonb type is the flexibility it gives you — you can store whatever structure you need without defining columns up front. But that flexibility comes with a trade-off: there's nothing stopping bad data from getting in. You can slap a CHECK constraint on a jsonb column, but writing validation logic in SQL or PL/pgSQL for anything beyond the trivial gets ugly fast.

I've been working on a PostgreSQL extension called json_schema_validate that solves this problem by letting you validate JSON and JSONB data against JSON Schema specifications directly in the

Dave Page: AI Features in pgAdmin: The AI Chat Agent

Tue, 10 Mar 2026 05:44:17 +0000

This is the second in a series of three blog posts covering the new AI functionality in pgAdmin 4. In the first post, I covered LLM configuration and the AI-powered analysis reports. In this post, I'll introduce the AI Chat agent in the query tool, and in the third, I'll explore the AI Insights feature for EXPLAIN plan analysis.If you've ever found yourself staring at a database schema you didn't design, trying to work out the right joins to answer a seemingly simple question, you'll appreciate what the AI Chat agent brings to pgAdmin's query tool. Rather than having to alt-tab to an external AI service, paste in your schema, describe what you need, and then copy the resulting SQL back into your editor, the entire conversation now happens within the query tool itself, with full awareness of your actual database structure.

Finding the AI Assistant

The AI Chat agent appears as a new tab alongside the Query and Query History tabs in the left panel of the query tool. It's labelled 'AI Assistant' and is only visible when an LLM provider has been configured (as described in the first post in this series). The panel header shows which LLM provider and model are currently active, so you always know what's generating your responses.

Natural Language to SQL

The core capability of the AI Chat agent is translating natural language questions into SQL queries. You type what you want to know in plain English (or whatever language you're comfortable with), and the assistant generates the corresponding SQL, complete with an explanation of what it does and why it was written that way.For example, you might type something like:The assistant will first inspect your database schema to understand the available tables and relationships, then generate an appropriate query. The response includes both the SQL and a brief explanation, so you can understand what the query is doing before you run it.What makes this particularly useful is that the assistant doesn't just guess at your schema; it actively inspects the database using a[...]

Yuwei Xiao: Introducing pg_duckpipe: Real-Time CDC for Your Lakehouse

Tue, 10 Mar 2026 00:00:00 +0000

Automatically keep a fast, analytical copy of your PostgreSQL tables, updated in real time with no external tools needed.

Umair Shahid: Thinking of PostgreSQL High Availability as Layers

Mon, 09 Mar 2026 14:03:16 +0000

High availability for PostgreSQL is often treated as a single, big, dramatic decision: “Are we doing HA or not?”

That framing pushes teams into two extremes:

a “hero architecture” that costs a lot and still feels tense to operate, or
a minimalistic architecture that everyone hopes will just keep running.

A calmer way to design this is to treat HA and DR as layers. You start with a baseline, then add specific capabilities only when your RPO/RTO and budget justify them.

Let us walk through the layers from “single primary” to “multi-site DR posture”.

Start with outcomes

Before topology, align on three things:

1. Failure scope

A database host fails
A zone or data center goes away
A full region outage happens
Human error

2. RPO (Recovery Point Objective)

We can tolerate up to 15 minutes of data loss
We want close to zero

3. RTO (Recovery Time Objective)

We can be back in 30 minutes
We want service back in under 2 minutes

Here is my stance (and it saves money!): You get strong availability outcomes by layering in the right order.

Layer 0 – Single primary (baseline, no backups)

This is the baseline: one PostgreSQL primary in one site. All reads and writes go to it.

That is it. No replicas. No archiving. No backup flow in this model.

What you get:

simplicity
low cost
low operational overhead

What it means operationally:

Your “recovery plan” is effectively “rebuild and rehydrate from wherever you can” (which might be

[...]

Cornelia Biacsics: Contributions for week 9, 2026

Mon, 09 Mar 2026 10:31:43 +0000

The community met on Wednesday, March 4, 2026 for the 7. PostgreSQL User Group NRW MeetUp (Cologne, ORDIX AG). It was organised by Dirk Krautschick and Andreas Baier.

Speakers:

Robin Riel
Jan Karremans

PostgreSQL Berlin March 2026 Meetup took place on March 5, 2026 organized by Andreas Scherbaum and Sergey Dudoladov.

Speakers:

Andreas Scherbaum
Tudor Golubenco
Narendra Tawar
Kai Wagner

Kai Wagner wrote about his experience at the meetup PostgreSQL Berlin Meetup - March 2026

Andreas Scherbaum wrote a blog posting about the Meetup.

SCALE 23x (March 5-8, 2026) had a dedicated PostgreSQL track, filled by the following contributions

Trainings:

Elizabeth Christensen
Devrim Gunduz
Ryan Booz

Talks:

Nick Meyer
Tristan Ahmadi
Alexandra Wang
Christophe Pettus
Max Englander
Magnus Hagander
Bruce Momjian
Robert Treat
Payal Singh
German Eichberger
Jimmy Angelakos
Justin Frye

SCALE 23x PostgreSQL Booth volunteers:

Bruce Momjian
Christine Momjian
Gabrielle Roth
Jennifer Scheuerell
Magnus Hagander
Devrim Gunduz
Elizabeth Garret Christensen
Robert Treat
Pavlo Golub
Phill Vacca
Jimmy Angelakos
Erika Miller
Aya Griswold
Alex Wood
Donald Wong
Derya Gumustel

Dave Page: AI Features in pgAdmin: Configuration and Reports

Mon, 09 Mar 2026 05:31:29 +0000

This is the first in a series of three blog posts covering the new AI functionality coming in pgAdmin 4. In this post, I'll walk through how to configure the LLM integration and introduce the AI-powered analysis reports; in the second, I'll cover the AI Chat agent in the query tool; and in the third, I'll explore the AI Insights feature for EXPLAIN plan analysis.Anyone who manages PostgreSQL databases in a professional capacity knows that keeping on top of security, performance, and schema design is an ongoing endeavour. You might have a checklist of things to review, or perhaps you rely on experience and intuition to spot potential issues, but it is all too easy for something to slip through the cracks, especially as databases grow in complexity. We've been thinking about how AI could help with this, and I'm pleased to introduce a suite of AI-powered features in pgAdmin 4 that bring large language model analysis directly into the tool you already use every day.

Configuring the LLM Integration

Before any of the AI features can be used, you'll need to configure an LLM provider. pgAdmin supports four providers out of the box, giving you flexibility to choose between cloud-hosted models and locally-running alternatives:

Anthropic
(Claude models)

OpenAI
(GPT models)

Ollama
(locally-hosted open-source models)

Docker Model Runner
(built into Docker Desktop 4.40 and later)

Server Configuration

At the server level, there is a master switch in (or, more typically, ) that controls whether AI features are available at all:When is set to , all AI functionality is hidden from users and cannot be enabled through preferences. This gives administrators full control over whether AI features are permitted in their environment, which is particularly important in organisations with strict data governance policies.Below the master switch, you'll find default configuration for each provider:For the cloud providers (Anthropic and OpenAI), API keys are read from files on di[...]

Radim Marek: Production Query Plans Without Production Data

Sun, 08 Mar 2026 21:15:56 +0000

In the previous article we covered how the PostgreSQL planner reads pg_class and pg_statistic to estimate row counts, choose join strategies, and decide whether an index scan is worth it. The message was clear: when statistics are wrong, everything else goes with it.

Streaming replication provides bit-to-bit replication, so all replicas share the same statistics with primary server.

But there was one thing we didn't talk about. Statistics are specific to the database cluster that generated them. The primary way to populate them is `ANALYZE` which requires the actual data.

PostgreSQL 18 changed that. Two new functions: pg_restore_relation_stats and pg_restore_attribute_stats write numbers directly into the catalog tables. Combined with pg_dump --statistics-only, you can treat optimizer statistics as a deployable artifact. Compact, portable, plain SQL.

The feature was driven by the upgrade use case. In the past, major version upgrades used to leave pg_statistic empty, forcing you to run ANALYZE. Which might take hours on large clusters. With PostgreSQL 18 upgrades now transfer statistics automatically. But that's just the beginning. The same logic lets you export statistics from production and inject them anywhere - test database, local debugging, or as part of CI pipelines.

The problem

Your CI database has 1,000 rows. Production has 50 million. The planner makes completely different decisions for each. Running EXPLAIN in CI tells you nothing about the production plan. This is the core premise behind RegreSQL. Catching query plan regressions in CI is far more reliable when the planner sees production-scale statistics.

Same applies to debugging. A query is slow in production and you want to reproduce the plan locally, but your database has different statistics, and planner chooses the predictable path. Porting production stats can provide you that snapshot of thinking planner has to do in production, without actually going to production.

pg_restore_relation_stats

The first of functi

[...]