Latest Blog Posts

FOSDEM 2026 — Defining "Drop-in Replacement" and Beyond
Posted by Jimmy Angelakos on 2026-02-06 at 18:00

Obligatory photo from FOSDEM 2026. Credit: Marcelo Altmann

Back from Brussels where I was doing the annual pilgrimage to the awesome FOSDEM gathering. I was very pleased to see the popularity and positive vibe of the (first time) joint Databases Devroom. Community-oriented and community-run conferences are the best IMHO.

It was great to share the stage this time with Daniël van Eeden, an engineer from PingCAP and a MySQL Rockstar. I enjoyed the collaboration because we approached a thorny issue from two different aspects: the PostgreSQL emerging standard and the implementation of MySQL compatibility.

The Talk: "Drop-in Replacement"

Our presentation, "Drop-in Replacement: Defining Compatibility for Postgres and MySQL Derivatives", tackled a problem in our industry: the "wild west" of marketing claims. The success of open source databases has created an ecosystem of derivatives claiming "drop-in compatibility."

The reality, however, is that this often leads to user confusion and brand dilution. As we discussed, compatibility is not an absolute Yes/No situation—even different versions of the same database are not 100% compatible due to deprecated or added features.

The Standard: The Riga Consensus

In my section of the talk, I focused on the governance perspective. I presented the findings from the "Establishing the PostgreSQL Standard" working group held at PGConf.EU 2025 in Riga last October.

We are pivoting from a binary "Pass/Fail" certification to a granular compatibility matrix. We need to ensure that when someone says "Postgres Compatible," they don't just mean matching the wire protocol. We need to look at:

  • Core SQL & Implicit Behaviours: It's not just about functions; it's about undocumented behaviors users rely on, like how INSERT ... SELECT ... ORDER BY behaves.
  • System Catalogs: Monitoring tools rely on the pg_catalog being present and predictable.
  • No Silent Failures: A command like CREATE INDEX must actually build the index, not just return "success" while doing nothing.

The Implementation: T

[...]

Prague PostgreSQL Dev Day – a very late follow up
Posted by Henrietta Dombrovskaya on 2026-02-06 at 16:00

Everyone who was in Prague on January 27-28 has already posted their feedback and moved on, so I am late, as it often happens. However, I still maintain that better late than never!

This year was the second time I attended this event, and this time, I didn’t have to rush out immediately after my training session, and was able to stay longer and to connect with many attendees. Same as last time, I was very impressed with the whole event organization, and a very warm and welcoming atmosphere at the event. Many thanks to Tomas Vondra!

I delivered the same workshop I did last year. Last year, I ran out of time despite my best efforts, and since I hate to be that presenter who doesn’t keep track of time and then rushes through the last twenty slides, I made an effort to remove the content I presumed I won’t take time to cover, in advance. It looks like I overdid it a little bit, because I ended up finishing earlier, but I think it’s still better than later 🙂

My usual lament about these training sessions is gender uniformity, and I still do not know what is the right solution for this problem!

Also, many thanks to Gülçin Yıldırım Jelínek for extending my 63-rd birthday celebraiton for another week 🙂

As it often happens, my only regret is that there were so many interesting talks happening at the same time! I could avoid FOMO if I would check out the Nordic PG schedule earlier, because some of the talks will be replayed there. I could plan it better! But in any case, I had a great time 🙂

Reading Buffer statistics in EXPLAIN output
Posted by Radim Marek on 2026-02-06 at 15:00

In the article about Buffers in PostgreSQL we kept adding EXPLAIN (ANALYZE, BUFFERS) to every query without giving much thought to the output. Time to fix that. PostgreSQL breaks down buffer usage for each plan node, and once you learn to read those numbers, you'll know exactly where your query spent time waiting for I/O - and where it didn't have to. That's about as fundamental as it gets when diagnosing performance problems.

PostgreSQL 18: BUFFERS by Default
Starting with PostgreSQL 18, EXPLAIN ANALYZE automatically includes buffer statistics - you no longer need to explicitly add BUFFERS. The examples below use the explicit syntax for compatibility with older versions, but on PG18+ a simple EXPLAIN ANALYZE gives you the same information.

A complete example

For this article we will use following schema and seeded data. 

CREATE TABLE customers (
    id integer GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name text NOT NULL
);

CREATE TABLE orders (
    id integer GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    customer_id integer NOT NULL REFERENCES customers(id),
    amount numeric(10,2) NOT NULL,
    status text NOT NULL DEFAULT 'pending',
    note text,
    created_at date NOT NULL DEFAULT CURRENT_DATE
);

INSERT INTO customers (name)
SELECT 'Customer ' || i
FROM generate_series(1, 2000) AS i;

-- seed data: ~100,000 orders spread across 2022-2025
INSERT INTO orders (customer_id, amount, status, note, created_at)
SELECT
    (random() * 1999 + 1)::int,
    (random() * 500 + 5)::numeric(10,2),
    (ARRAY['pending','shipped','delivered','cancelled'])[floor(random()*4+1)::int],
    CASE WHEN random() < 0.3 THEN 'Some note text here for padding' ELSE NULL END,
    '2022-01-01'::date + (random() * 1095)::int  -- ~3 years of data
FROM generate_series(1, 100000);

-- make sure stats are up to date
ANALYZE customers;
ANALYZE orders;

-- we are going to skip indexes on purpose

-- and fire sample query
select count(1) from customers;

Let's start with a random query 

EXPLAIN (ANALYZE, BUFFERS)
SELECT
[...]

Reducing row count estimation errors in PostgreSQL
Posted by Shinya Kato on 2026-02-06 at 05:41

Introduction

PostgreSQL's query planner relies on table statistics to estimate the number of rows (estimated rows) each operation will process, and then selects an optimal execution plan based on these estimates. When the estimated rows diverge significantly from the actual rows, the planner can choose a suboptimal plan, leading to severe query performance degradation.

This article walks through four approaches I used to reduce row count estimation errors, ordered from least to most invasive. Due to confidentiality constraints, I cannot share actual SQL or execution plans, so the focus is on the diagnostic thought process and the techniques applied.

Prerequisites

  • The approaches in this article are applicable to any modern PostgreSQL version, as the underlying mechanisms (autovacuum, pg_statistic, extended statistics) have been stable across versions
  • The target table had a high update frequency
  • Actual SQL and execution plans cannot be shared; this article focuses on methodology

Approach 1: Tuning autovacuum auto-ANALYZE frequency per table

The target table was known to have a very high update rate, so the first hypothesis was that the statistics were simply stale.

In PostgreSQL, the autovacuum daemon automatically runs ANALYZE to update statistics stored in pg_statistic. However, for tables with heavy write activity, auto-ANALYZE may not keep up with the rate of change, causing the statistics to drift from reality.

To address this, I adjusted the auto-ANALYZE frequency for the specific table rather than changing the server-wide settings in postgresql.conf.

The two key parameters are:

  • autovacuum_analyze_threshold: The minimum number of tuple modifications before auto-ANALYZE is triggered (default: 50)
  • autovacuum_analyze_scale_factor: The fraction of the table size added to the threshold (default: 0.1, i.e., 10%) 
ALTER TABLE table_name SET (
    autovacuum_analyze_threshold = 0,
    autovacuum_analyze_scale_factor = 0.01
);

In this ex

[...]

Postgres client_connection_check_interval
Posted by Jeremy Schneider on 2026-02-05 at 04:54

Saw this post on LinkedIn yesterday:

I also somehow missed this setting for years. And it’s crazy timing, because it’s right after I published a blog about seeing the exact problem this solves. In my blog post I mentioned “unexpected behaviors (bugs?) in… Postgres itself.” Turns out Postgres already has the fix; it’s just disabled by default.

It was a one-line change to add the setting to my test suite and verify the impact. As a reminder, here’s the original problematic behavior which I just now reproduced again:

At the T=20sec mark, TPS drops from 700 to around 30. At T=26sec the total connections hit 100 (same as max_connections) and then TPS drops to almost zero. This total system outage continues until T=72sec when the system recovers after the blocking session has been killed by the transaction_timeout setting.

So what happens if we set client_connection_check_interval to 15 seconds? Quick addition to docker-compose.yml and we find out!

Fascinating! The brown line and the red line are the important ones. As before, the TPS drops at T=20sec and zeros out after we hit max_connections. But at T=35sec we start to see the total connection count slowly decrease! This continues until T=42sec when the PgBouncer connections are finally released – and at this point we repeat the whole cycle a second time, as the number of total connections climbs back up to the max.

So we can see that the 15 second client_connection_check_interval setting is working exactly as expected (if a little slowly) – at the 15 second mark Postgres begins to clean up the dead connections.

What if we do a lower setting like 2 seconds?

This looks even better! The total connections climbs to around 30-ish and holds stable there. And more importantly, the TPS never crashes out all the way to zero and the system is able to continue with a small workload until the blocking session is killed.

There is definitely some connection churn happening here (expected due to golang context timeouts) an

[...]

MCP Transport: Architecture, Boundaries, and Failure Modes
Posted by Ibrar Ahmed in pgEdge on 2026-02-05 at 04:51

You can prototype an impressive agent in a notebook, but you can’t run one in production without a transport strategy. The Model Context Protocol standardizes how agents call tools and access memory, but it intentionally does not define how bytes move between systems. That responsibility sits with your architecture. Most teams treat transport as an implementation detail, and default to whatever works in a development container. That shortcut becomes technical debt the moment the system faces real traffic. The symptoms are predictable: 

  • Latency becomes inconsistent under load. 
  • Streams stall without clear failure signals. 
  • Security boundaries blur between internal and external systems. 
These are not edge cases. They are the inevitable outcome of using transport designed for convenience rather than reliability.In a production environment, transport failure creates availability incidents. Model failures create incorrect answers or stop the system from working. Transport failure can also produce a bad output while the system stays online. Because of this, transport design belongs in reliability engineering, not just in application plumbing. Transport defines how quickly agents respond, how failures propagate, how systems recover, and how safely tools and memory services are exposed. When transport design conflicts with infrastructure reality, agents appear unstable even when tool logic and model behavior are correct. Stability in agent systems is determined at boundaries, not inside components.This post examines the three dominant MCP transport models used in production systems. 
  • stdio MCP provides process-level isolation and the lowest possible latency for same-host execution. 
  • HTTP with Server-Sent Events enables cluster-scale orchestration, shared tool services, and internal memory systems. 
  • HTTPS with Server-Sent Events enforces encryption and identity guarantees across trust boundaries, including customer, partner, and multi-organization environments.
You will learn w[...]

History Repeats Itself
Posted by Richard Yen on 2026-02-04 at 17:00

Over 15 years later, some solutions are still great solutions

Introduction

OpenAI recently shared their story about how they scaled to 800 million users on their ChatGPT platform. With the boom of AI in the past year, they’ve certainly had to deal with some significant scaling challenges, and I was curious how they’d approach it. To sum it up, they addressed the following issues with the following solutions:

  • Reducing load on the primary (offloaded read-only queries to replicas)
  • Query optimization (query tuning and configuring timeouts like idle_in_transaction_session_timeout)
  • Single point of failure mitigation (configured hot-standby for high-availability)
  • Workload isolation (implemented a software solution for load-balancing)
  • Connection pooling (deployed pgBouncer)
  • Cache misses (implemented a cache locking mechanism)
  • Scaling read replicas (implemented cascading replication)
  • Resource exhaustion (implemented rate-limiting, tuned ORM)
  • Full table rewrites on schema changes (enforced strict DML policies)

Indeed, there was a lot of work put in to scale to “millions of queries per second (QPS)” and I applaud their team for implementing these solutions to handle the unique challenges that they faced. 👏👏👏

Taking a Walk Down Memory Lane

While reading through their post, I couldn’t help but think to myself, wow, some of the solutions they used are not much different from ours 15 years ago! Fifteen years ago, I was the head DBA at Turnitin (called iParadigms at the time). Times were different back then, before the massive boom of social media (Instagram wasn’t a thing at the time!), and we were all on-prem, switching from spindle-based disk to SSDs. At that time, we were likewise facing challenges scaling to 3000 QPS to serve up data to students and teachers across the US, Canada, and the UK. Our founders were making a lot of headway in promoting Turnitin to secondary schools and universities, and we were regularly facing the struggle of having “just enou

[...]

pgstream v1.0.0: Stateless schema change replication
Posted by Esther Minano in Xata on 2026-02-04 at 15:58
A major architectural milestone that removes schema logs and simplifies how pgstream captures and replicates Postgres schema changes

The "Skip Scan" You Already Had Before v18
Posted by Robins Tharakan on 2026-02-04 at 13:05

PostgreSQL 18 introduces native "Skip Scan" for multicolumn B-tree indexes, a major optimizer enhancement. However, a common misconception is that pre-v18 versions purely resort to sequential scans when the leading column isn't filtered. In reality, the cost-based planner has long been capable of leveraging such indexes when efficient.

How it works under the hood:

In pre-v18 versions, if an index is significantly smaller than the table (the heap), scanning the entire index to find matching rows—even without utilizing the tree structure to "skip"—can be cheaper than a sequential table scan. This is sometimes also referred as a Full-Index Scan. While this lacks v18’s ability to hop between distinct leading keys, it effectively still speeds up queries on non-leading columns for many common workloads.

Notably, we would see why this v18 improvement is not a game-changer for all workloads, and why you shouldn't assume speed-up for all kinds of datasets.

Benchmarks: v17 vs v18

To understand when the new v18 Skip Scan helps, we tested two distinct scenarios.

Scenario A: Low Cardinality (The "Success" Case)

The Setup: We created an index on (bid, abalance) and ran the following query: 

SELECT COUNT(*) FROM pgbench_accounts WHERE abalance = -2187;

Note: We did not run a read-write workload, so abalance is 0 for all rows. The query returns 0 rows.

Data Statistics:

  • Table Rows: 1,000,000
  • Leading Column (bid): ~10 distinct values (Low Cardinality).
  • Filter Column (abalance): 1 distinct value (Uniform).

Results:

Version Strategy TPS Avg Latency Buffers Hit
v17 Index Only Scan (Full) ~2,511 0.40 ms 845
v18 Index Only Scan (Skip Scan) ~14,382
[...]

PGDay and FOSDEM Report from Kai
Posted by Kai Wagner in Percona on 2026-02-04 at 10:00

The following thoughts and comments are completely my personal opinion and do not reflect my employers thoughts or beliefs. If you don’t like anything in this post, reach out to me directly, so I can ignore it ;-).

I’m currently on the train on my way back home from FOSDEM this year and man, I’m exhausted but also happy. Why? Because the PG and FOSDEM community is just crazily awesome. While it’s always too much of everything, it’s at the same time inspiring to see so many enthusiastic IT nerds in one place, discussing and working on what they love - technology and engineering challenges.

PostgreSQL Materialized Views: When Caching Your Query Results Makes Sense (And When It Doesn’t)
Posted by Umair Shahid in Stormatics on 2026-02-03 at 09:17

The Pain and the Real Constraint

Your dashboard queries are timing out at 30 seconds. Your BI tool is showing spinners. Your users are refreshing the page, wondering if something’s broken.

You’ve indexed everything. You’ve tuned shared_buffers. You’ve rewritten the query three times. The problem isn’t bad SQL – it’s that you’re forcing PostgreSQL to aggregate, join, and scan millions of rows every single time someone opens that report.

Here’s a clear stance: repeated heavy computations are a design choice, not a badge of honour. If you’re running the same expensive calculation dozens of times a day, you’re choosing to do more work than necessary.

This post shows you how to turn one expensive query shape into a fast, indexed object with explicit freshness and operational control. Materialized views give you predictable reads when you’re willing to accept a refresh contract.

What a Materialized View Actually Is (and What It Is Not)

Definition in Plain Words

A materialized view is a physical relation that stores the result set of a query.

When you create one, PostgreSQL runs your query, writes the output to disk, and keeps it there until you tell it to refresh. That’s it. No magic. Just a snapshot you control.

Compare the Three Common Patterns

Let’s be precise about what you’re choosing:

View: Computed at read time, always current. PostgreSQL rewrites your query against the underlying tables every time. Zero staleness, full computation cost on every read.

Materialized view: Computed at refresh time, fast reads. You decide when to refresh. Reads are fast and predictable because they’re hitting stored data. Staleness is explicit and bounded by your refresh schedule.

Summary table: You own the update pipeline. Whether it’s ETL jobs, application code, or triggers—you’re writing the insert/update logic and managing incremental changes yourself.

Why the “Physical” Part Matters

[...]

Importance of Tuning Checkpoint in PostgreSQL
Posted by Jobin Augustine in Percona on 2026-02-02 at 15:04
Importance of Tuning Checkpoint in PostgreSQLThe topic of checkpoint tuning is frequently discussed in many blogs. However, I keep coming across cases where it is kept untuned, resulting in huge wastage of server resources, struggling with poor performance and other issues. So it’s time to reiterate the importance again with more details, especially for new users. What is a checkpoint? […]

Null and Empty String in Oracle vs SQL Server vs PostgreSQL
Posted by Akhil Reddy Banappagari in HexaCluster on 2026-02-02 at 11:46
When you are planning database migrations to PostgreSQL, it is usually the small things that cause the biggest production bugs. One of the most common traps for developers is how different databases handle NULL and empty strings ('').

Contributions for week 1-4, 2026
Posted by Cornelia Biacsics in postgres-contrib.org on 2026-02-02 at 09:39

The Nordic PGDay 2026 Call for Paper Committee met to finalize the talk selection:

  • Georgios Kokolatos
  • Louise Leinweber
  • Liisa Hämäläinen
  • Thea Stark

PGDay Paris 2026 schedule has also been announced — talk selection was made by:

  • Pavlo Golub
  • Sarah Conway
  • Valeria Kaplan

On Monday, January 26, the Prague PostgreSQL Meetup: January Edition met. It was organized by Mayuresh B. Gulcin Yildirim Jelinek.

Speaker:

  • Teresa Lopes
  • Josef Machytka
  • Luigi Nardi

Prague PostgreSQL Dev Day 2026 (P2D2) happened from January 27 - January 28.

Organized by:

  • Pavel Hák
  • Matěj Klonfar
  • Jan Pěček
  • Ellyne Phneah
  • Pavel Stěhule
  • Tomáš Vondra
  • Aleš Zelený

Talk selection committee:

  • Pavlo Golub
  • Pavel Hák
  • Hana Litavská
  • Teresa Lopes
  • Mayur B
  • Esther Miñano
  • Josef Šimánek
  • Pavel Stěhule
  • Tomáš Vondra

Workshops:

  • Hettie Dombrovskaya
  • Jonathan, Danish
  • Tomas Vondra
  • Nazir Bilal Yavuz
  • Josef Machytka
  • Pavlo Golub

Talks:

  • Cagri Biroglu
  • Jakub Kuzela
  • Alexander Kukushkin
  • Kranthi Kiran Burada
  • Narendra Tawar
  • Bruce Momjian
  • Anton Borisov
  • Mohsin Ejaz
  • Petr Šmejkal
  • Michal Bartak
  • Gulcin Yildirim Jelinek
  • Teresa Lopes
  • Ants Aasma
  • Robert Treat
  • Luigi Nardi
  • Peter Zaitsev
  • Grant Fritchey
  • Radim Marek
  • Adam Wolk

Lightning talks:

  • Mayuresh B.
  • Michal Bartak
  • Sergey Chehuta
  • Alijaz Mur Erzen
  • Josef Machytka
  • Henrietta Dombrovskaya
  • Ants Aasma
  • Jonathan Battiato
  • Ellyne Phneah
  • Mohsin Ejaz
  • Anton Borisov
  • Luigi Nardi

PostgreSQL was represented at FOSDEM’26 which took place from January 31 - February 1

Databases Devroom Speakers:

  • Rohit Nayak
  • Shlomi Noach
  • Ben Dicken
  • Pep Pla
  • Jimmy Angelakos
  • Daniël van Eeden
  • Nicoleta Lazar
  • Charly Batista
  • Greg Potter
  • Kevin Biju
  • Georgi Kodinov
  • Sunny Ba
[...]

pgagroal 2.0.0 is available!
Posted by Luca Ferrari on 2026-02-02 at 00:00

The new major release of the fast connection pooler for PostgreSQL has been released!

pgagroal 2.0.0 is available!

It took quite a lot of time to get from version 1.6.0 to the new major version 2.0.0, but the new pgagroal is finally here! The project went thru two Google Summer of Code (GSoC 2025 and 2024) before this new great release was completed, but the project decided to prefer the code stability over the rush in releasing, and I think you are going to be amazed by how much improvements have been collapsed in this new version.

The official release note has been sent today.

The new features

There are a lot of new features and small gems in this 2.0.0 release, it is pretty much impossible to describe all of them here, but here it is a concise list of what you can expect from this new version.

The new event system

pgagroal has been event-driven from the very beginning, using the libev library for handling input/output in a more fast and scalable way.

The project decided to move from libev from something more modern and better mantained, and the natural choice for Linux operating systems was io_uring (yes, the same used in PostgreSQL 18) and kqueue for BSD systems. io_uring is an async method for read and write operations that aims at peformances, while kqueue is an event driven approach for FreeBSD and OpenBSD systems.

The key point here is event-driven and, obviously, asynchronous. The whole event management has been rewritten to wrap compatible structures and functions wherever possible. Performances have increased a lot from the 1.x releases.

The new management protocol

The management protocol is the way pgagroal-cli and pgagroal interact each other: it sends commands to the daemon and get back responses.

The new release provides a new fully rewritten management protocol that now speaks entirely JSON. Moreover, the protocol is now more robust and error tolerant. Moreover, every command and response now include the application and daemon version, so that it

[...]

Hackorum - A Forum-Style View of pg-hackers
Posted by Kai Wagner in Percona on 2026-02-02 at 00:00

Last year at pgconf.dev, there was a discussion about improving the user interface for the PostgreSQL hackers mailing list, which is the main communication channel for PostgreSQL core development. Based on that discussion, I want to share a small project we have been working on:

https://hackorum.dev/

Hackorum provides a read-only (for now) web view of the mailing list with a more forum-like presentation. It is a work-in-progress proof of concept, and we are primarily looking for feedback on whether this approach is useful and what we should improve next.

FOSDEM 2026: €400 Repetto Heels, Recursive CTEs, and Europe's Tech Sovereignty Wake-Up Call
Posted by Lætitia AVROT on 2026-02-01 at 00:00
The Honor Part (That I’m Still Processing) 🔗Let me start with the big one: I was invited to the European Open Source Awards ceremony on Thursday evening. Not “bought a ticket” invited—actually invited. If you know the European Union, you know this is invitation-only, and honestly, I’m still a bit stunned. So, picture me, finally seated in my seat on the train, ready to go and checklisting everything. I have the dress, the belt, the purse, the jewels, even the hair accessories.

Same SQL, Different Results: A Subtle Oracle vs PostgreSQL Migration Bug
Posted by Deepak Mahto on 2026-01-30 at 14:52

Read time: ~6 minutes

A real-world deep dive into operator precedence, implicit casting, and why database engines “don’t think the same way”.

The Database Migration Mystery That Started It All

You migrate a perfectly stable Oracle application to PostgreSQL.

  • The SQL runs
  • The tests pass
  • The syntax looks correct
  • Nothing crashes

And yet… the numbers or query calculations are wrong.

Not obviously wrong. Not broken. Just different.
Those are the worst bugs the ones that quietly ship to production. This is a story about one such bug, hiding behind familiar operators, clean-looking conversions, and false confidence.

The Original Business Logic (Oracle)

Here’s a simplified piece of real production logic used to compute a varhour value from timestamp data:

CASE
WHEN TO_CHAR(varmonth,'MI') + 1 = 60
THEN varhr - 1 || TO_CHAR(varmonth,'MI') + 1 + 40
ELSE varhr - 1 || TO_CHAR(varmonth,'MI') + 1
END AS varhour

At first glance, this feels routine:

  • Extract minutes
  • Perform arithmetic
  • Concatenate values

Nothing here screams “migration risk”.

The Migration Illusion: “Looks Correct, Right?”

During migration, teams don’t blindly copy Oracle SQL. They do the right thing make types explicit and clean up the logic.

Here’s the PostgreSQL converted version, already “fixed” with necessary casts:

SELECT
CASE WHEN TO_CHAR(varmonth, 'MI') :: integer + 1 = 60
THEN
(end_hr -1) :: text || TO_CHAR(varmonth, 'MI')::integer + 1 + 40
ELSE
(end_hr -1)::text || TO_CHAR(varmonth, 'MI') ::integer + 1
END varhour
FROM sample_loads
ORDER BY id;

No syntax errors. Explicit casting. Clean and readable. At this point, most migrations move on.

Side-by-Side: Oracle vs PostgreSQL (At First Glance)

Let’s compare the two versions:

[...]

Panel Discussion: How to Work with Other Postgres People — PGConf.EU 2025
Posted by Jimmy Angelakos on 2026-01-29 at 13:37

I have to apologise — it's been months since PGConf.EU 2025 in Riga, and I'm only now publishing this video. The delay was due to wanting to create accurate captions for the recording, which unfortunately took longer than expected.

In this session, Floor Drees, Karen Jex, and I joined host Boriss Mejias to examine how diverse minds work together in the PostgreSQL ecosystem. We touched upon the psychology of teamwork and the importance of accommodating neurodiverse conditions like ADHD and ASD.

A pleasant surprise for us during the session was the level of engagement from the audience. People connected deeply with the subject matter, turning the panel talk into a real conversation where we shared practical hacks — body doubling, "Pomodoro playlists", tactile focus tools like knitting, crocheting, and full-body fidget toys, and experiences with managers who actually "get it".

Building awareness is the first step on a journey that can lead to better outcomes for everyone. We do believe some things need to be adapted, and we can work together to make this gradual change happen.

Without further ado, I present the panel discussion below. I will be very happy to hear back from you at @vyruss@fosstodon.org — your comments, your experiences, your testimonials. This is how we continue to raise awareness together.

Video on YouTube: youtube.com/watch?v=PsxNhcBTrTU

Unlocking High-Performance PostgreSQL: Key Memory Optimizations
Posted by warda bibi in Stormatics on 2026-01-29 at 07:30

PostgreSQL can scale extremely well in production, but many deployments run on conservative defaults that are safe yet far from optimal. The crux of performance optimization is to understand what each setting really controls, how settings interact under concurrency, and how to verify impact with real metrics.

This guide walks through the two most important memory parameters:

  • shared_buffers
  • work_mem 

shared_buffers

Let’s start with shared_buffers, because this is one of the most important concepts in PostgreSQL. When a client connects to PostgreSQL and asks for data, PostgreSQL does not read directly from disk and stream it back to the client. Instead, PostgreSQL does something that pulls the required data page into shared memory first and then serves it from there. The same design applies to writes. When the client updates a row, PostgreSQL does not immediately write that change to disk. It loads the page into memory, updates it in RAM, and marks that page as dirty. Disk writes come later.

And this design is intentional because reading and writing in memory are orders of magnitude faster than reading from or writing to disk, and it dramatically reduces random I/O overhead.

So what exactly is shared_buffers?

shared_buffers defines the size of the shared memory region that PostgreSQL uses as its internal buffer cache. And all the reads and writes go through shared_buffers. Disk interaction happens later asynchronously through background writing and checkpoints. So shared_buffers is the layer between the database processes and the disk.

Image Credits: https://shrturl.app/a2zfKi

By default, PostgreSQL sets shared_buffers to 128MB. That might be fine for local environments; however, it is not enough cache for real working sets, which means more disk reads, more I/O pressure, and less s

[...]

How to Use the pgEdge MCP Server for PostgreSQL with Claude Cowork
Posted by Antony Pegg in pgEdge on 2026-01-29 at 05:18

The rise of agentic AI is transforming how we build applications, and databases are at the center of this transformation. As AI agents become more sophisticated, they need reliable, real-time access to data.If you’ve decided to use an MCP server for exposing data to large language models (LLMs) to build internal tools for trusted users, apply sophisticated database schema changes, or translate natural language into SQL, you might find the pgedge-postgres-mcp project (available on GitHub) useful to try.This 100% open source Natural Language Agent for PostgreSQL provides a connection between any MCP-compatible client (including AI assistants like Claude) and any standard flavor of Postgres, whether you’re creating a new greenfield project or are using an existing database.

Connecting AI agents to PostgreSQL with pgedge-postgres-mcp

The Model Context Protocol (MCP) is a standardized way for AI assistants to communicate with external data sources. Think of MCP as a universal adapter; just as USB-C provides a standard connection for devices, MCP provides a standard way for AI agents to connect to tools, databases, and services.pgedge-postgres-mcp implements this protocol specifically for PostgreSQL, creating a bridge between AI assistants and your data. It enables users to:
  • Query databases using natural language
  • Execute SQL queries safely in read-only transactions
  • Access local or distributed PostgreSQL instances
  • Work with production data safely (read-only by default)
  • Interact with database schemas and metadata
Instead of writing custom integration code for each AI application, you get a ready-to-use connection between AI agents and your PostgreSQL database. It works with any PostgreSQL instance, whether you're running locally for development or hosting remotely.

Benefits for AI Development

The pgEdge MCP Server solves a specific problem: giving AI assistants database access without building custom middleware, with configurable controls for authentication, read-only transacti[...]

500 Milliseconds on Planning: How PostgreSQL Statistics Slowed Down a Query 20 Times Over
Posted by Andrei Lepikhov in pgEdge on 2026-01-28 at 15:25

A query executes in just 2 milliseconds, yet its planning phase takes 500 ms. The database is reasonably sized, the query involves 9 tables, and the default_statistics_target is set to only 500. Where does this discrepancy come from?

This question was recently raised on the pgsql-performance mailing list, and the investigation revealed a somewhat surprising culprit: the column statistics stored in PostgreSQL's pg_statistic table.

The Context

In PostgreSQL, query optimisation relies on various statistical measures, such as MCV, histograms, distinct values, and others - all stored in the pg_statistic table. By default, these statistics are based on samples of up to 100 elements. For larger tables, however, we typically need significantly more samples to ensure reliable estimates. A thousand to 5000 elements might not seem like much when representing billions of rows, but this raises an important question: could large statistical arrays, particularly MCVs on variable-sized columns, seriously impact query planning performance, even if query execution itself is nearly instantaneous?

Investigating the Problem

We're examining a typical auto-generated 1C system query. '1C' is a typical object-relational mapping framework for accounting applications. PostgreSQL version is 17.5. Notably, the default_statistics_target value is set to only 500 elements, even below the recommended value for 1C systems (2500). The query contains 12 joins, but 9 are spread across subplans, and the join search space is limited by three JOINs, which is quite manageable. Looking at the EXPLAIN output, the planner touches only 5 buffer pages during planning - not much.

Interestingly, the alternative PostgreSQL fork (such forks have become increasingly popular these days) executed this query with nearly identical execution plans, and the planning time is considerably shorter - around 80 milliseconds. Let's use this as our control sample.

The Hunt for Root Cause

The first suspicion was obvious: perhaps the developer

[...]

New Presentation
Posted by Bruce Momjian in EDB on 2026-01-28 at 14:00

I just gave a new presentation at Prague PostgreSQL Developer Day titled What's Missing in Postgres? It's an unusual talk because it explains the missing features of Postgres, and why. One thing I learned in writing the talk is that the majority of our missing features are performance-related, rather than functionality-related. I took many questions:

  • some pointed out that extensions supply much of this missing functionality
  • some supported the lack of features because the features are either unnecessary or harmful
  • some features are in-progress

Thanks to Melanie Plageman for the idea of this talk.

Migrating Sybase ASE aka SAP ASE to PostgreSQL
Posted by Avi Vallarapu in HexaCluster on 2026-01-28 at 11:04
Legacy Sybase ASE/SAP ASE databases are still powering mission-critical OLTP workloads, but modernization pressure keeps rising. Witness the differences between SAP ASE and PostgreSQL, and the migration path to PostgreSQL.

Why Your HA Architecture is a Lie (And That's Okay)
Posted by Lætitia AVROT on 2026-01-28 at 00:00
If Darth Vader existed and decided to do to Earth what he did to Alderaan, everyone would lose data. I love this quote from Robert Haas because it’s a reality check we all need. In the database world, we’re constantly sold the dream of “Five Nines” (99.999% uptime) and “Zero Data Loss” (RPO1 0). We spend months building complex clusters to achieve it. Let’s be honest: these are fairy tales. Beautiful to imagine, but they don’t exist in production.

Unused Indexes In PostgreSQL: Risks, Detection, And Safe Removal
Posted by semab tariq in Stormatics on 2026-01-27 at 09:57

Indexes exist to speed up data access. They allow PostgreSQL to avoid full table scans, significantly reducing query execution time for read-heavy workloads.

From real production experience, we have observed that well-designed, targeted indexes can improve query performance by 5× or more, especially on large transactional tables.

However, indexes are not free.

And in this blog, we are going to discuss what issues unused indexes can cause and how to remove them from production systems with a rollback plan, safely

1. Why Unused Large Indexes Become a Long-Term Problem

Over time, unused indexes can silently degrade database performance. Below are some of the most common issues they cause in production systems.

1.1. Slower INSERT, UPDATE, And DELETE Operations

Every write operation must update all indexes on a table, including those that are never used by queries.

1.2. Increased Vacuum And Autovacuum Overhead

Indexes accumulate dead tuples just like tables. These must be vacuumed, increasing I/O usage and extending vacuum runtimes.

1.3. Longer Maintenance Windows

Operations such as VACUUM and REINDEX take longer as the number and size of indexes grow.

1.4. Disk Space Waste And Cache Pollution

Large unused indexes consume disk space and can evict useful data from shared buffers, reducing cache efficiency.

Because of these reasons, it is always recommended to periodically identify and safely remove unused indexes from production systems, but only through a controlled and well-validated process.

2. How To Safely Drop Unused Indexes In PostgreSQL

Below is a step-by-step, production-safe checklist that should be followed before dropping any index.

2.1. Check When System Statistics Were Last Reset

If statistics were reset recently, an index may appear unused even though it is actively required by workloads. 

SELECT
  datname,
  stats_re
[...]

How to render timestamp with a timezone that is different from current?
Posted by Hubert 'depesz' Lubaczewski on 2026-01-27 at 09:25
This question appeared on IRC, and while I wasn't there while it happened, it caught my eye: » Can I not render this with timezone offset: select ‘2026-01-09 04:35:46.9824-08'::timestamp with time zone at time zone ‘UTC'; » Returns ‘2026-01-09 12:35:46.9824' which is without the offset. Let's see what can be done about it. First, let's … Continue reading "How to render timestamp with a timezone that is different from current?"

Is the future of MySQL PostgreSQL (Or MariaDB, or TiDB, or ...)?
Posted by Dave Stokes on 2026-01-25 at 16:45

 I am not intentionally trying to upset anyone with this blog post or minimize the efforts of many brilliant people whom I admire. However, I connected with several people over the 2025 holidays who all had the same question: What is the future of MySQL? At the upcoming FOSDEM conference, several events will discuss this subject and push a particular solution.  And in several ways, they are all wrong.

Oracle has not been improving the community edition for a long time now. They have laid off many of their top performers in the MySQL group. We got almost a good decade and a half out of Oracle's stewardship of the "world's most popular database", and we should be thankful for that. However, now that time is over, it is time to consider future options that will involve no updates, CVEs, or innovation for what is the MySQL Community Edition.

There are several choices available.

Nothing!

The first choice is nothing. Many folks run old, end-of-life versions of MySQL. There are many instances of MySQL 5.7. There are some fantastic features in later versions of the software. But if those features are not needed or desired, then why upgrade? MySQL has always had a minimalist appeal for those who have little need for features like JSON, material views, and the like. This vanilla approach will be the default for many who do not change it if it is still working in the school of software management. 

Pros: You do not have to make any changes.
Cons: You are taking on technical debt like the Titanic took on water. You may get a few years out of this, but this path is fraught with hungry dragons.

The Elephant

PostgreSQL? This is a great database, offering numerous valuable features and making it a solid choice. It is reasonably easy to port schemas and data from MySQL to PostgreSQL. You will want to run a connection pooler. You will need to keep an eye on the vacuum status. You will need to learn to pick from an embarrassing number of indexing options, with B+ tree probably still being your prima

[...]

PostgreSQL Anonymizer, available in all good shops
Posted by damien clochard in Dalibo on 2026-01-25 at 12:30

As we prepare for the upcoming release of PostgreSQL Anonymizer 3.0, I took some time to check which platforms now support the extension. What I discovered brought me a sense of achievement that I wanted to share with the community.

More and More Platforms Are Embracing Data Anonymization

Over the past months, several major Cloud Service Providers have adopted the PostgreSQL Anonymizer extension, making it easier than ever for organizations to protect sensitive data.

The new adopters include:

They add to the current list composed of Alibaba Cloud, Crunchy Bridge, Google Cloud SQL, Microsoft Azure Database, Neon and others

Growing Support Across PostgreSQL Forks

Perhaps even more remarkable is the adoption by major PostgreSQL forks and enterprise distributions. Each of these platforms has its own specific requirements and user base, and seeing PostgreSQL Anonymizer integrated across this ecosystem is truly humbling:

Please refer to their own documentation on how to activate the extension as they might have a platform-specific install procedure.

Beyond PostgreSQL: The Django Integration

I’ve also noticed a Django plugin for PostgreSQL Anonymizer, making it easier for Python developers to integrate data anonymization into their applications.

Reflecting on our journey

When we started working on PostgreSQL Anonymizer in 2018, the goal was simple: provide a straightforward way to mask personal information directly within PostgreSQL. We wanted to make privacy-preserving techniques accessible to anyone using PostgreSQL, without requiring complex and expansive external tools or ETLs.

Seeing this level of adoption across cloud providers, enterprise distributions, and even extending into application frameworks is incredibly rewarding. But it’s important to remember that this success belongs to everyone who contr

[...]

🛠️ PGXN Tools v1.7
Posted by David Wheeler on 2026-01-24 at 22:53

Today I released v1.7.0 of the pgxn-tools OCI image, which simplifies Postgres extension testing and PGXN distribution. The new version includes just a few updates and improvements:

  • Upgraded the Debian base image from Bookworm to Trixie
  • Set the PGUSER environment variable to postgres in the Dockerfile, removing the need for users to remember to do it.
  • Updated pg-build-test to set MAKEFLAGS="-j $(nprocs)" to shorten build runtimes.
  • Also updated pgrx-build-test to pass -j $(nprocs), for the same reason.
  • Upgraded the pgrx test extension to v0.16.1 and test it on Postgres versions 13-16.

Just a security and quality of coding life release. Ideally existing workflows will continue to work as they always have.

Top posters

Number of posts in the past two months

Top teams

Number of posts in the past two months

Feeds

Planet

  • Policy for being listed on Planet PostgreSQL.
  • Add your blog to Planet PostgreSQL.
  • List of all subscribed blogs.
  • Manage your registration.

Contact

Get in touch with the Planet PostgreSQL administrators at planet at postgresql.org.