Last week, we attended the annual PGConf.dev as a Gold-level sponsor. While most PostgreSQL conferences usually attract users and DBAs, this event draws a strong mix of contributors and community members alike, making it a unique opportunity to get proposals and patches reviewed and to connect across the broader Postgres ecosystem.
Our team played a major role behind the scenes. Robert Haas helped organize the event, tackling the impressive feat of shaping Tuesday's content across six tracks. Additionally, Jacob Champion served on the Talk Selection Committee, and Phil Alger, Manni Wood
Thanks to the organising team, I had the chance to attend PGConf.dev last week in Vancouver, Canada. And luckily, I wasn’t alone there — Valeria could join as well!
This year’s edition was particularly special: we celebrated 30 years of open source PostgreSQL together! Many activities revolved around the anniversary, including a special celebration-themed conference t-shirt, stickers, commemorative posters, and more.
My personal highlight was definitely Wednesday’s round-table retrospective, which brought together project founders and early contributors to reflect on PostgreSQL’s formative years and its remarkable evolution. Featuring Bruce Momjian, Tom Lane, Thomas Lockhart, Jan Wieck, Vadim Mikheev, and Jolly Chen, the discussion revisited what the Postgres project was like in its earliest open source incarnation — technically, culturally, and socially.
Then, on Thursday, a birthday cake cutting ceremony took place following a short speech from Bruce Momjian.
Even though the project still relies on decisions made in its early days — such as hacker mailing-list-focused discussions and documentation written close to the source code using DocBook — it is hard to imagine where PostgreSQL will be 10 or 20 years from now.
Especially today, with AI-assisted content generation accelerating code writing (though not necessarily code review!), the project will inevitably evolve. But as Jan Wieck concluded during the panel, we should take care to preserve and foster the PostgreSQL spirit.
After the panel, a group photo was organised. I can’t wait to see the result!
Speaking of pictures, a photo booth was set up to let attendees take funny pictures celebrating PostgreSQL’s 30th anniversary. As member of the PGDay Lowlands 2026 talk selection committee, I couldn’t resist taking a picture together with Floor Drees, who was the only representative from the organising team attending the event.
This year’s PGConf.dev schedule was divided into three parts.
Tuesda
[...]A field report from PGConf Dev 2026 — and a working framework for everyone who has to keep AI workloads running in production.
A production AI batch job is stuck. Sixty thousand rows are locked. Your application performance is degrading. The post-mortem the next morning will be filed under “unknown cause.”
Here is what actually happened, minute by minute:
The root cause has a name, but it’s a name the industry hasn’t agreed on yet: external call state held inside an open transaction. There is no alert for it. There is no entry in the runbook. There is no metric you can graph. The post-mortem says “unknown cause” because we don’t yet have a shared vocabulary for this failure mode.
I gave a talk at PGConf Dev about this and a class of related production incidents. By the end of the session, I wanted the audience to walk away with two things: enough technical understanding to fix something on Monday morning, and enough conceptual vocabulary to argue for the right primitives in the Postgres community.
This post is the long-form version of that talk. It introduces a five-letter framework — ORBIT — that maps every failure mode I’ll discuss to one of five principles, and shows how the same framework applies whether you’re an SRE staring at a pager, an Enterp
[...]If you have a slow query, one of the obvious moves is to add an index. So you look at the WHERE clause, pick a column, run CREATE INDEX, and test again. Sometimes it helps, often it doesn’t. And now you have an index sitting there, not helping reads, but slowing down every write, because INSERT, UPDATE, and DELETE all have to maintain it. And it gets worse as your system grows.
Five queries are manageable. You can reason about column choices, test combinations, and check EXPLAIN output. When you are dealing with fifty queries across a dozen tables, you are evaluating hundreds of possible column combinations manually, each one potentially breaking something in production if you get the locking wrong.
Most people know that indexes speed up reads. Fewer people think carefully about what actually happens when they add one.
First, PostgreSQL might not use it. The planner compares strategies and picks the cheapest one. If your query touches a large fraction of the table, a sequential scan might actually be cheaper than an index scan. Creating the index doesn’t change that math, it just adds overhead.
Second, even with CONCURRENTLY, creating an index on a busy table isn’t free. It competes with your workload, can cause replication lag, and sometimes it times out. People don’t plan for this until it happens at 2am.
Third, and this one is subtle, adding the wrong index is sometimes worse than adding nothing. You pay the write overhead with zero read benefit.
The harder part is column ordering. A composite index on (status, customer_id) and one on (customer_id, status) are completely different things. The planner’s decision about which one to use depends on your data distribution, which conditions appear in your WHERE clause, and how selective each column is. Getting this wrong by hand is easy. Verifying it without touching production is the real challenge.
Logical replication has come a long way since its introduction in PostgreSQL. It is now being adopted more widely than ever, powering cross-version upgrades, multi-region deployments, and real-time analytics pipelines. Yet significant opportunities for improvement still remain.
This series is aimed at recounting, explaining, and cataloging issues pertaining to Postgres in large-scale production environments that affected a wide section of users and clients. The idea occured to me when discussing one specific issue (covered in a later part in this series) that was my first experience dealing with such issues on a wide scale (multiple clients and clusters affected). This specific part focuses on issues that were caused not by Postgres itself, but by the tools, OS, and ecosystems that Postgres relies on.
Three of the worst Postgres incidents I have read postmortems for did not start in Postgres. They started one layer down: the kernel, glibc, the page allocator. Postgres handled the input correctly given what it was told.
I want to cover these first because the fixes are cheap and most teams still ship without them.
For years, Postgres assumed that if fsync() returned success, the data was on disk, and if it returned an error, it could be retried. Linux did neither. Under writeback errors on some filesystems, the kernel cleared the error after the first reader saw it. The next fsync() returned success while pages were still dirty in memory and never made it to disk.
This came to be known as fsyncgate. The fix in Postgres was to PANIC on fsync() failure (PG 11+), forcing recovery from WAL instead of trusting the OS to retry. There is also data_sync_retry, which you almost certainly want set to off.
What this means for an operator:
fsync semantics. Many do not, and the docs rarely say so plainly.
For the long version of how this came to light on the pgsql-hackers list, Jonathan Corbet's PostgreSQL's fsync() surprise on LWN is the canonical writeup.
The Iceberg tables look like normal Postgres tables. You create them with USING iceberg and they're backed by Parquet on S3:
Postgres engines now have access to more data than ever. With extensions like pg_lake, you can connect Postgres to gobs of files in object storage like csv, json, Apache Parquet™ and Apache Iceberg™.
But having access to data in object storage and being able to aggregate data in object storage are two different things. This blog walks through the Postgres extension, Apache AGE™, that makes working with huge files of data sets much friendlier through graph relationships.
Let's consider a healthcare network with providers, patients, facilities and referral chains. The analytical questions are straightforward:
SQL on Iceberg handles all of these beautifully. But if you need to know: "Which in-network providers are referring patients to out-of-network providers through chains of intermediaries, and what's the dollar impact?" Those questions have two parts: a graph traversal (find the referral chains) and an analytical aggregation (sum the costs). Neither a pure graph database nor a pure analytical engine can answer it alone. You need both, working together, in the same query.
This is where data lakes need graphs.
Apache AGE is a PostgreSQL extension that adds openCypher graph query support directly inside Postgres. There are other graph databases out there — Neo4j, Amazon Neptune, TigerGraph — but AGE has a unique advantage for the modern data platform — it runs inside PostgreSQL.
We've recently seen customers increasingly using Apache AGE for a couple of reasons:
PGConf.dev is an annual developer event focused entirely on contributing to the PostgreSQL ecosystem, including core software development and community building. It serves as a primary hub for PostgreSQL hackers, maintainers, and ecosystem developers to meet, collaborate, and share knowledge.
This year’s conference was hosted once again in Vancouver, which also happens to be my hometown :D. On top of that, 2026 also marks PostgreSQL’s 30th anniversary, giving this year’s conference an even more meaningful atmosphere for long-time contributors and community members around the world.
This is one of my favorite PostgreSQL conferences because it gives people an opportunity to truly meet, learn from, and interact with the brilliant minds behind PostgreSQL. Many of the names we usually only see in hacker mailing list discussions, patch reviews and commit messages suddenly become real people standing right beside you, discussing ideas and working together to make PostgreSQL better.
It feels like the PostgreSQL hacker discussions have come to life in the real world. The conversations are real, the passion is real, and the community spirit is everywhere.
A huge thank you once again to all the organizers, volunteers, speakers, and sponsors who invested countless hours to make this conference possible. This blog is a personal summary of my own experience attending pgconf.dev 2026, and for those who could not attend, I hope it can give you at least a small glimpse of what it feels like to be part of this incredible PostgreSQL community.
Unlike the “Tuesdays” from previous pgconf.dev conferences, this year’s Tuesday schedule is packed with an impressive variety of engaging sessions, including round-table discussions, interviews, keynote-style talks, brainstorming sessions, and community-led discussions focused on spe
[...]PostgreSQL uses MVCC (Multi-Version Concurrency Control) for concurrency control: reads never block writes, and writes never block reads.
Its locking system has 8 table-level lock modes and 4 row-level lock modes, and the conflict tables in the documentation tell you exactly which lock modes conflict with which.
In practice, though, once you actually operate PostgreSQL, locks end up conflicting in places you never expected. Queries take far longer than anticipated, and in the worst case you end up with an outage.
This article walks through five of these counterintuitive locking behaviors.
ACCESS EXCLUSIVE request is queued, subsequent queries get blocked in a chain
The first one: an ALTER TABLE that should finish instantly can bring your entire service to a halt.
Suppose one session is running a long SELECT on table t, and another session runs the following ALTER TABLE:
Session 1
SELECT pg_sleep(600) FROM t LIMIT 1; -- a long-running SELECT
Session 2
ALTER TABLE t ADD COLUMN name text;
Since Session 1 holds an ACCESS SHARE lock on table t, the ACCESS EXCLUSIVE lock that Session 2's ALTER TABLE requires is forced to wait. So far, this is expected behavior.
But PostgreSQL's lock waiting works like a FIFO queue. While the ACCESS EXCLUSIVE lock is waiting, any SELECT issued against table t afterward gets stuck behind it — even though that SELECT does not conflict with Session 1's currently running SELECT at all.
[...]Besides a long-running
SELECT, the same thing happens with a session that ran aSELECTinside aBEGINtransaction and then left it open withoutCOMMIT/ROLLBACK(a so-called idle in transaction session). AnACCESS SHARElock is held until the transaction ends, so even if theSELECTitself finished in an instant, simply forgetting to close the transaction will keep blockingALTER TABLE. This is often caused by
For a long time, PGCon in Ottawa was a staple for the PostgreSQL community. I always had a soft spot for Ottawa; it fondly reminded me of my childhood days in Pune. So, when it was first announced that the reincarnated PGConf.dev would take place in Vancouver, I felt a twinge of sadness.
However, the moment I landed in Vancouver, all my reservations dissolved. The city won me over instantly—from riding a bicycle along the seawall and admiring the beautiful totem poles, to watching the Gastown Steam Clock. Returning this year, I was incredibly happy to explore Stanley Park on foot once again.
But as beautiful as Vancouver is, the real magic happened inside the venue.
This year’s event kicked off with a brand-new addition: the Tuesday community discussions. It turned out to be so packed with value that it felt like getting two conferences in a single week—just like the advertisement in my hotel elevator promised!
I conducted a session to discuss the priorities and future of graph database offerings in PostgreSQL, specifically focusing on SQL/PGQ and Apache/AGE. Given that SQL/PGQ is a newly-committed feature, I expected a modest turnout of about a dozen people. To my surprise, over 25 people attended, and most actively participated in the debate.
Logical Replication: While it has come a long way over the last decade, there is still a long road ahead. We dove deep into DDL replication and replication in multi-tenant, multi-DB clusters. My main takeaway? There are still a few missing pieces before logical replication can be effectively leveraged for high-volume OLAP use cases.
Multithreading: This ambitious effort aims to replace Postgres's traditional process-driven architecture with threads. As I fondly like to say: it’s like replacing an elephant’s heart with a cougar’s
I’m back home from Vancouver. What a great week – in every way. I’ll try to share a few highlights here.
First and foremost: after many years, the Happiness Hints have received a major update! Before the conference, I updated the hints based on all the feedback I’ve collected over the past few years. Then the hints were updated into a poster format and we printed it as part of the pgconf.dev poster session. Throughout the week, I continued collecting more feedback. I used a sharpie during the conference and marked up the poster with ideas. Special thanks to Laurenz Albe, David Rader, Sami Imseih, Ryan Booz and Nik Samokhvalov (Nik you weren’t at the conference but a happiness hint resulted from other discussions we’ve had). Of course I’m forgetting more people who gave feedback making the happiness hints better. After coming home from the conference, I incorporated all the notes I had – and the version that’s now published here at ardentperf.com is the latest & best version I’ve assembled so far.
An extraordinary number of postgres users rely on physical replication for high availability. It’s been around for a long time and it works well. Nonetheless, there are a few rough edges and over the years there have been various mailing list threads that haven’t fully been resolved.
I proposed a Friday unconference session on this topic, and the topic received enough votes to be selected. Notes from the unconference are available on the Postgres wiki. But the discussion extended far beyond the unconference; there were also hallway discussions over coffee (thanks Thomas Munro) and then continuing discussions over dinner at Joey Burrard and beers at Steamworks (thanks Ants Aasma).
The first question that everybody asks is “should postgres have more HA capabilities in core”? And a discussion starting along these lines consumed the first half of the unconference.
But I thought the most interesting train of
[...]This story started with a book gifted by a colleague. Reading Jimmy Angelakos' «PostgreSQL Mistakes and How to Avoid Them», I realised something that had been bugging me - in Postgres, the EXPLAIN command produces far too much information. The examples that authors typically present when discussing various aspects of database systems make it harder to analyse the problem at hand and distract the reader. That's how the idea of a post-processing for EXPLAIN output was born - to make query plans more readable and problem-focused.
The technology industry is entering a fascinating phase where many older ideas are suddenly becoming critically important again. Concepts that once lived mostly inside data governance discussions, library sciences, enterprise architecture diagrams, semantic web research, and metadata catalogs are now being pulled directly into the center of modern AI conversations. This shift is not accidental. As organizations move from AI experimentation to real enterprise deployment, they are discovering that intelligence does not come only from models. It also depends on how well the organization understands, organizes, governs, and connects its data.
Over the last two years, terms such as context engineering, AI memory, semantic retrieval, knowledge-driven agents, and context-aware systems have rapidly entered mainstream technology discussions. Vendors now describe platforms as intelligent because they can retrieve documents semantically, maintain conversational memory, or connect AI systems to enterprise knowledge. At first glance, this sounds entirely new. In reality, much of the industry is rediscovering a foundational truth that enterprise architects, database professionals, and information management practitioners have understood for years: AI systems cannot reason reliably without meaningful data.
This is not simply a model problem. It is fundamentally a data architecture problem. Large Language Models are extraordinarily capable at generating language, summarizing content, writing code, and answering questions conversationally. However, enterprises are increasingly discovering that language generation alone does not create trustworthy intelligence. An AI system may generate answers that sound convincing while still lacking operational correctness, governance awareness, relationship understanding, or contextual grounding.
This is precisely why concepts such as metadata, semantics, taxonom
[...]The Night When Things Almost Went Down
Have you ever left for home on a Friday evening feeling confident about your work for the day, at peace knowing your system would survive the coming weekend? We’ve all felt that way at some point.
Meanwhile, the disk on the server had quietly reached 90% utilization. Write-Ahead Log (WAL) files had accumulated enormously, one long-running query had been running for over an hour, and nobody noticed because, some time earlier, the dashboard had looked fine.
After a while, writes to the database started to fail, and you received messages like, “Hey, the DB seems a bit slow?” In reality, the database was no longer slow; it had already gone down.
However, this wasn’t anything new. The signs of trouble had been there the entire time. The monitoring simply wasn’t connected to the right signals to raise the alarm.
And that’s what this post is about.
Let’s be honest. Dashboards are great for screenshots.
However, they make one risky assumption that someone will make this check before it’s too late. Alerts make no such assumption.
A dashboard gently shows an increasing CPU. But an alert rings, saying: “This has been bad for 30 minutes, wake up.”
Dashboards are waiting for us. But alerts find us. After a few incidents, we no longer rely on the dashboard to keep us safe while asleep. It’s through alerts that it happens.
These rules are set up by going to Alerting → Alert Rules in the PMM interface and creating a New Alert Rule. For every alert, we need to configure three things:
Duration: How long the condition must hold before the alert fires. This filters out temporary sp
At the end of April, I had the incredible opportunity to represent credativ on the HOW2026 (Hello Open-source World), the PostgreSQL & IvorySQL Eco Conference in Jinan, China. IvorySQL is a Chinese fork of PostgreSQL with extended Oracle compatibility. In recent years, it has been gaining popularity not only in China. The conference brought together PostgreSQL and IvorySQL experts, contributors, and open-source database enthusiasts from around the world. The atmosphere was excellent, and I would like to share several highlights together with a recap of my contributions.
I was honored to contribute to the HOW2026 program with two sessions.
On Sunday afternoon, I led a three-hour deep-dive workshop exploring the intricate mechanics of PostgreSQL shared buffers. I discussed how Linux implements shared memory operations through the tmpfs file system, how shared buffers work internally, their practical limitations and usage patterns, why and how huge pages should be used for their allocation, why transparent huge pages negatively affect performance, and practical strategies for balancing high concurrency with optimal system performance.
On Tuesday afternoon, I gave a talk focused on PostgreSQL connection overhead. I discussed how PostgreSQL connections interact with the Linux kernel, covering memory usage, physical memory allocation mapping, context-switching overhead, and PostgreSQL internals to explain why large numbers of connections can significantly degrade performance.
PGConf.dev 2026 took place from May 19-22 2026, organized by
Program Committee:
Tuesday Planning Committee:
Code of Conduct Committee:
Volunteers:
Speakers (including Tuesday Community Sessions & Lightning Talks):
I recently wrote a post about WAL log shipping and how a standby built on log shipping is a great way to give data analysts production data without putting the primary at risk. Having access to the production data in this way is great, but it’s read-only. How can we create views of this data for better analytics work? I want to make the case today that Foreign Data Wrappers and Materialized Views can make a great solution – not only in accessing production Postgres data, but also working with other data sources.
Most people meet foreign data wrappers (FDWs) through a quick demo, and I’ve highlighted some of their features in previous conference talks. There is high novelty in being able to query MySQL from Postgres, but the reality is often that the latency between the local database and the foreign table can be pretty high. Sometimes, predicate push-down isn’t what you’d expect, and indexing may not be very transparent. In the end, setting up and managing FDWs may seem more work than it’s worth, and that’s a mistake. Used correctly, foreign tables are one of the most practical tools for analytics across heterogeneous data sources – especially when paired with materialized views.
Modern data rarely lives in one place:
Foreign tables give you a unified SQL interface, but under the hood, the query performance can be unpredictable as you may be forced to rely on another engine’s query planner (and in the case of that CSV data source, it might not even be indexed).
In other words, FDWs optimize developer experience, not query performance.
Instead of querying foreign tables directly in analytics workloads, we can opt to use FDWs as ingestion points, not as the servi
[...]Number of posts in the past two months
Christophe Pettus (pgExperts) - 91 Vibhor Kumar - 9 Richard Yen - 8 Cornelia Biacsics (postgres-contrib.org) - 8 Shaun Thomas (pgEdge) - 7 Antony Pegg (pgEdge) - 7 Henrietta Dombrovskaya - 6 Radim Marek - 6 Hubert 'depesz' Lubaczewski - 5 Lætitia AVROT - 5Number of posts in the past two months
Get in touch with the Planet PostgreSQL administrators at planet at postgresql.org.
