Sammlung von Newsfeeds

This quarter's round of minor releases are expected later this week. Note this will be the last minor release for PostgreSQL 13 .

New podcast episode published by Claire Giordano from her series “Talking Postgres” : Building a dev experience for Postgres in VS Code with Rob Emanuele

Blog posts

• Ellyne Phneah Key takeaways from the PostgreSQL & AI Summit: RAG, agents, and tuning

PostgreSQL 19 changes this week EXPLAIN wal_fpi_bytes value exposed in EXPLAIN (WAL) pg_stat_wal column wal_fpi_bytes added pg_stat_get_backend_wal() output column wal_fpi_bytes added psql prompt configuration option %S added, showing the current value of search_path PostgreSQL 19 articles Waiting for PostgreSQL 19 – Add psql PROMPT variable for search_path.

Postgres has an awesome amount of data collected in its own internal tables. Postgres hackers know all about this  - but software developers and folks working with day to day Postgres tasks often miss out the good stuff.

The Postgres catalog is how Postgres keeps track of itself. Of course, Postgres would do this in a relational database with its own schema. Throughout the years several nice features have been added to the internal tables like psql tools and views that make navigating Postgres’ internal tables even easier.

I'm happy to announce release 0.8 of pg_statviz, the minimalist extension and utility pair for time series analysis and visualization of PostgreSQL internal statistics.

This release adds support for PostgreSQL 18, adapting to significant catalog view changes introduced in this release:

PostgreSQL 13 will officially reach End-of-Life (EOL) on November 13, 2025. After this date, the PostgreSQL Global Development Group will stop releasing security patches and bug fixes for this version. That means if you’re still running PostgreSQL 13, you’ll soon be on your own with no updates, no community support, and growing security risks. Why […]

In the third installment of the PostGIS Performance series, I wanted to talk about performance around bounding boxes.

Geometry data is different from most column types you find in a relational database. The objects in a geometry column can be wildly different in the amount of the data domain they cover, and the amount of physical size they take up on disk.

PostgreSQL 19 changes this week ALTER SUBSCRIPTION : REFRESH SEQUENCES syntax added error_on_null() added for checking if the input is the NULL value COPY TO now works with partitioned tables full text search : database default collation now used for parsing psql : Improve tab completion for large objects. PostgreSQL 19 articles PostgreSQL 18 articles Waiting for PostgreSQL 19 – Support COPY TO for partitioned tables. (2025-10-22) - Hubert 'depesz' Lubaczewski Say Hello to OIDC in PostgreSQL 18!

Upgrading to a new major version of PostgreSQL has become faster and safer with pg_upgrade, but for teams using logical replication, a persistent pain point remained: the state of their subscribers was lost, forcing a tedious and high-risk rebuild of their replication setups.

When communicating UUID-v7 values to third parties, the creation dates inside them are leaked. In this post, let's see how to encrypt the timestamp to solve that problem.

Due to an unfortunate recent visitation by the Virus of the Decade (so far), I have a backlog of these which I'm trying to work through, so in the remote chance anyone is waiting with bated breath for the newest editions, my apologies. Normal service will be resumed as soon as humanly possible.

Almost a month late, but I hope you enjoy it!

PostgreSQL and NUMA, part 2 of 4

This series covers the specifics of running PostgreSQL on large systems with many processors. My experience is that people often spend months learning the basics when confronted with the problem. This series tries to dispel these difficulties by providing a clear background into the topics in question. The hope is that future generations of database engineers and administrators don’t have to spend months figuring things out through trial and error.

In one of our earlier blogs, we explored how improper volatility settings in PL/pgSQL functions — namely using IMMUTABLE, STABLE, or VOLATILE — can lead to unexpected behavior and performance issues during migrations.

As a database consulting company, we are often faced with analytics and reporting related tasks which seem to be easy on the surface but are in reality not that trivial. The number of those seemingly simple things is longer than one might think, especially in the area of reporting

I pushed the most boring change imaginable, add an index. Our CI/CD pipeline is textbook ==> spin up a fresh DB, run every migration file in one single transaction, in sequential manner. If anything hiccups, the whole thing rolls back and the change never hits main. Foolproof autotests.

Enter The Drama Queen :

As part of the new ABI compliance reporting system for the PostgreSQL Buildfarm, there has long been a question: if a Buildfarm run fails due to an ABI incompatibility, how can it be marked successful again once the ABI break is fixed? This post explains the introduction of a new file, .abi-compliance-history, in the PostgreSQL source tree and how it is used to track ABI breaks.

When using tsearch one usually, often, creates a tsvector column to put data in, and then create index on it. But, do you really need the index? I wrote once already that you don't have to, but then a person talked with me on IRC, and pointed this section of docs: One advantage of the … Continue reading "Do you really need tsvector column?"

As I explained in my talk on PostgreSQL Conference Europe 2025, data corruption can be silently present in any PostgreSQL database and will remain undetected until we physically read corrupted data. There can be many reasons why some data blocks in tables or other objects can be damaged. Even modern storage hardware is far from being infallible. Binary backups done with pg_basebackup tool – which is very common backup strategy in PostgreSQL environment – leave these problems hidden. Because they do not check data but copy whole data files as they are.

Beyond Start and End columns with PostgreSQL range types

One of the most read articles at boringSQL is Time to Better Know The Time in PostgreSQL where we dived into the complexities of storing and handling time operations in PostgreSQL. While the article introduced the range data types, there's so much more to them. And not only for handling time ranges.