Latest Blog Posts

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.

Introduction to Buffers in PostgreSQL
Posted by Radim Marek on 2026-01-24 at 16:15

The work around RegreSQL led me to focus a lot on buffers. If you are a casual PostgreSQL user, you have probably heard about adjusting shared_buffers and followed the good old advice to set it to 1/4 of available RAM. But after we went a little bit too enthusiastic about them on a recent Postgres FM episode I've been asked what that's all about.

Buffers are one of those topics that easily gets forgotten. And while they are a foundation block of PostgreSQL's performance architecture, most of us treat them as a black box. This article is going to attempt to change that.

The 8KB page

There's one concept we need to cover before diving into the buffers. And that's the concept of the 8KB page. Everything in PostgreSQL is stored in blocks that are 8KB wide.

When PostgreSQL reads the data, it does not read individual rows. It reads the entire page. When it writes something, same thing - same page. You want to retrieve one small row, you will always retrieve much more data to go along with it. And if you followed carefully, same applies to writes. 

-- you can check the block size (which should be almost always 8192 bytes)
show block_size;

 block_size
------------
 8192
(1 row)

Every table and index is a collection of these pages. A row might span multiple pages if it's large enough, but the page remains the atomic unit of I/O.

PostgreSQL vs OS

The interesting part is understanding why PostgreSQL needs to maintain its own infrastructure for its own buffer cache, when the operating system can already cache disk pages.

The answer is quite simple. PostgreSQL understands the data it reads. Whilst the operating system only sees files and bytes. PostgreSQL sees tables, indexes, query plans and has semantic knowledge to cache things faster.

Consider this example: a query needs to perform a sequential scan of a large table. The OS might happily cache all those pages, but PostgreSQL knows this is a one-time operation and uses a special strategy (ring buffers) to avoid eviction of the main cac

[...]

CSI: Postgres — Did someone change my table??
Posted by Kaarel Moppel on 2026-01-23 at 22:00
PostgreSQL has many small “hidden gem” features included (not to mention ~1K extensions adding a bunch more) waiting for someone to notice them. Some are useful every day, some are niche, and some (e.g. debug_* settings) exist only so that core developers could troubleshoot things without losing too much hair....

What's New in the pgEdge Postgres MCP Server: Beta 2 and Beta 3
Posted by Dave Page in pgEdge on 2026-01-23 at 05:34

When we released the first beta of the pgEdge Postgres MCP Server back in December, we were excited to see the community's response to what we'd built. Since then, the team has been hard at work adding new capabilities, refining the user experience, and addressing the feedback we've received. I'm pleased to share what's landed in Beta 2 (now available) and what's coming in Beta 3 (currently in QA).

Beta 2: Write Access, Token Efficiency, and a Better CLI

Beta 2 represents a significant step forward in making the pgEdge Postgres MCP Server more capable and more efficient.

Write Access Mode

Perhaps the most requested feature since we launched has been the ability to do more than just query data. In Beta 2, we've introduced an optional write access mode that allows the LLM to execute DDL and DML statements when enabled.This feature is disabled by default - safety first - but when you do enable it via the  configuration option, the server will permit CREATE, DROP, ALTER, INSERT, UPDATE, and DELETE operations. We've also added automatic schema metadata refresh after DDL operations, so  always returns current information.To ensure users are always aware when they're connected to a write-enabled database, we've added visual warnings throughout the interfaces. The web client displays a prominent amber warning banner, whilst the CLI shows a [] indicator in the database listing and warns you when switching to such a database. We want there to be no ambiguity about what the LLM can and cannot do.

Token Management Improvements

Anyone who's worked with LLMs knows that token usage matters - both for cost and for context window management. Beta 2 introduces several features designed to reduce token consumption.The new  tool provides a lightweight way to check the size of a table before querying it. Rather than fetching data only to discover you've got millions of rows, you can now get a count first and plan your query accordingly.We've also added pagination support to  with an  parameter, allowing you to page throu[...]

Send Emails like Oracle UTL_SMTP using pg_utl_smtp for PostgreSQL
Posted by Gilles Darold in HexaCluster on 2026-01-22 at 20:43
As part of its automated migration solution, HexaRocket, to simplify Enterprise-grade Oracle to PostgreSQL database migrations, HexaCluster is pleased to announce pg_utl_smpt PostgreSQL extension to create Oracle UTL_SMTP compatibility.

PostgreSQL Contributor Story: Florin Irion
Posted by Floor Drees in EDB on 2026-01-22 at 12:35
In 2025 we started a program to help colleagues who show promise for PostgreSQL Development to become contributors. In this post we highlight Florin's journey, a Staff SDE at EDB based in Italy.

CERN PGDay: an annual PostgreSQL event in Geneva, Switzerland
Posted by Sarah Conway in Data Bene on 2026-01-22 at 00:00

If you’re located near Western Switzerland and the Geneva region (or you just want to visit!), you might find it well worth your time to attend CERN PGDay 2026. It’s an annual gathering for anyone interested in learning more about PostgreSQL that takes place at CERN, the world’s largest particle physics laboratory.

If you find the subject of particle physics interesting, you may want to visit anyways! They offer free access to many activities that run from Tuesday to Sunday; you can view the full programme here.

Here, you’ll be able to attend a single track of seven English-language sessions, with a social gathering afterwards to enjoy CERN while continuing to connect with the rest of the attendees.

This year, there’ll be:

  1. A new PostgreSQL backend for CERN Tape Archive scheduling for LHC Run 4 - Konstantina Skovola, CERN
  2. DCS Data Tools - PostgreSQL/TimescaleDB Implementation for ATLAS DCS Time-Series Data - Dimitrios Matakias, Paris Moschovakos, CERN
  3. Operational hazards of managing PostgreSQL DBs over 100TB - Teresa Lopes, Adyen
  4. Vacuuming Large Tables: How Recent Postgres Changes Further Enable Mission Critical Workloads - Robert Treat, AWS
  5. The (very practical) Postgres Sharding Landscape - Álvaro Hernández, OnGres
  6. The Alchemy of Shared Buffers: Balancing Concurrency and Performance - Josef Machytka, credativ
  7. When Kafka Met Elephant: A Love Story about Fast Ingestion - Barbora Linhartova, Jan Suchanek, Baremon

The first talk of the day is of particular note…

The CERN Tape Archive (CTA) stores over one exabyte of scientific data. To orchestrate storage operations (archival) and access operations (retrieval), the CTA Scheduler coordinates concurrent data movements across hundreds of tape servers, relying on a Scheduler Database (Scheduler DB) to manage the metadata of the in-flight requests. The existing objectstore-based design of the CTA Scheduler DB is a complex transactional management system. This talk presents

[...]

Understanding ALTER TABLE Behavior on Partitioned Tables in PostgreSQL
Posted by Chao Li in Highgo Software on 2026-01-21 at 08:53

Partitioned tables are a core PostgreSQL feature, but one area still causes regular confusion—even for experienced users:

How exactly does ALTER TABLE behave when partitions are involved?

Does an operation propagate to partitions? Does it affect future partitions? Does ONLY do what it claims? Why do some commands work on parents but not on partitions—or vice versa?

Today, PostgreSQL documentation describes individual ALTER TABLE sub-commands well, but it rarely explains their interaction with partitioned tables as a whole. As a result, users often discover the real behavior only through trial and error.

This post summarizes a systematic investigation of ALTER TABLE behavior on partitioned tables, turning scattered rules into a consistent classification model.

The Problem: “Inconsistent” Is Not the Same as “Undocumented”

The PostgreSQL community often describes ALTER TABLE behavior on partitioned tables as inconsistent. In practice, the deeper problem is that:

  • The rules do exist, but

  • They are spread across code paths, error messages, and historical decisions, and

  • They are not documented in a way that lets users predict outcomes.

Without a mental model, even simple questions become hard to answer:

  • If I run this on the parent, what happens to existing partitions?

  • What about partitions created later?

  • Does ONLY prevent propagation—or is it ignored?

  • Can I override settings per partition?

How I Evaluated Each ALTER TABLE Sub-command

To make sense of this, I tested ALTER TABLE sub-commands against partitioned tables using the same set of questions each time.

Four evaluation criteria

For every sub-command, I asked:

  1. Propagation
    Does the action on a parent partitioned table propagate to existing partitions?
  2. Inheritance for new partitions
    If I create a new partition later, does it inherit
[...]

PDXPUG February 19th, 2026: What’s New in PostgreSQL 18
Posted by Mark Wong on 2026-01-20 at 21:58

2026 Thursday February 19th Meeting 6:30pm:8:30pm

Please note the new meeting location. And please RSVP on MeetUp as space is limited.

Location: Multnomah Arts Center – The front desk can guide you to the meeting room.

7688 SW CAPITOL HWY • PORTLAND, OR  97219

Speaker: Mark Wong

PostgreSQL 18 was released September 25, 2025.

We will review freely available presentations available on the internet.

Come learn what’s new, share experiences, or just meet with local peers! Casual, informal.

https://www.meetup.com/pdxpug/events/312977438/

Postgres Serials Should be BIGINT (and How to Migrate)
Posted by Elizabeth Garrett Christensen in Crunchy Data on 2026-01-20 at 13:00

Lots of us started with a Postgres database that incremented with an id SERIAL PRIMARY KEY. This was the Postgres standard for many years for data columns that auto incremented. The SERIAL is a shorthand for an integer data type that is automatically incremented. However as your data grows in size, SERIALs and INTs can run the risk of an integer overflow as they get closer to 2 Billion uses.

We covered a lot of this in a blog post The Integer at the End of the Universe: Integer Overflow in Postgres a few years ago. Since that was published we’ve helped a number of customers with this problem and I wanted to refresh the ideas and include some troubleshooting steps that can be helpful. I also think that BIGINT is more cost effective than folks realize.

SERIAL and BIGSERIAL are just shorthands and map directly to the INT and BIGINT data types. While something like CREATE TABLE user_events (id SERIAL PRIMARY KEY) would have been common in the past, the best practice now is BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY is recommended. SERIAL/ BIGSERIAL are not SQL standard and the GENERATED ALWAYS keyword prevents accidental inserts, guaranteeing the database manages the sequence instead of a manual or application based addition.

  • INT - goes up to 2.1 Billion (2,147,483,647) and more if you do negative numbers. INT takes up 4 bytes per row column.
  • BIGINT- goes up 9.22 quintillion (9,223,372,036,854,775,807) and needs a 8-bytes for storage.

Serials vs UUID

Before I continue talking about serials in Postgres, it is worth noting that Postgres also has robust UUID support, including v7 which was just released. If you decide to go with UUID, great. This makes a ton of sense for things that can be URLs or are across systems. However not all ids need to be UUIDs, so lots of folks still continue with a serialized / incremented integers.

Cost difference between INT and BIGINT

Postgres does not pack data tightly like a text file. It writes data in aligned tuples /  rows, and sta

[...]

PostgreSQL on Kubernetes vs VMs: A Technical Decision Guide
Posted by Umair Shahid in Stormatics on 2026-01-20 at 11:01

If your organization is standardizing on Kubernetes, this question shows up fast:

“Should PostgreSQL run on Kubernetes too?”

The worst answers are the confident ones:

  • “Yes, because everything else is on Kubernetes.”
  • “No, because databases are special.”

Both are lazy. The right answer depends on what you’re optimizing for: delivery velocity, platform consistency, latency predictability, operational risk, compliance constraints, and, most importantly, who is on-call when things go sideways.

I have seen PostgreSQL run very well on Kubernetes. I’ve also seen teams pay a high “complexity tax” for benefits they never actually used. This post is an attempt to give you a technical evaluation you can use to make a decision that fits your environment.

Start with the real question: are you running a database, or building a database platform?

This is the cleanest framing I have found:

  • Running a database: You have a small number of production clusters that are business-critical. You want predictable performance, understandable failure modes, straightforward upgrades, and clean runbooks.
  • Building a database platform: You want self-service provisioning, standardized guardrails, GitOps workflows, multi-tenancy controls, and a repeatable API so teams can spin up PostgreSQL clusters without opening tickets.

Kubernetes shines in the second world. VMs shine in the first.

Yes, you can do either on either platform. But the default fit differs.

A neutral comparison model: 6 dimensions that actually matter

Here is a practical rubric you can use in architecture reviews.

If you want a quick decision shortcut:

If your main goal is self-service and standardization, Kubernetes is compelling. If your main goal is pre

[...]

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.