Sammlung von Newsfeeds

 Features:

PostgreSQL 18 has just been born and we are already talking about the blessings of PostgreSQL 19 and beyond? Well, yes, and there is a good reason for it.

Back in July I submitted talks to the annual PostgreSQL Conference Japan 2025 (PostgreSQL カンファレンス 2025). This year is the 20th year of the conference, I was told. That is even longer running than our “own” PostgreSQL Conference Europe. To my surprise, one of my submitted talks was accepted. Which made me plan a trip to Japan and South Korea, to combine the conference

Earlier this year we started a program ("Developer U") to help colleagues who show promise for PostgreSQL Development to become contributors. Meet one of the participants: Akshay Joshi, a Principal Engineer and Engineering Manager at EDB.

PostgreSQL 19 changes this week COPY ...

On November 13th, 2025, we had the PostgreSQL November Meetup in Berlin. Redgate Software hosted us again, this time in a larger meeting room at The Social Hub Berlin. We had two speakers, and very tasty food. The event space is in Alexanderstraße 40, in Berlin Mitte. just five minutes away from Alexanderplatz. It is a event and gym venue, with several meeting rooms in various sizes, office area and a gym.

Seven PostgreSQL contributors completed this year of Google Summer Of Code:

Contributors:

• Ahmad Gouda
• Ashutosh Sh
• Bassam Adnan
• Gaurav Patidar
• Mankirat Singh
• Mohab Yasser
• Tejas Tyagi

Mentors:

The PostgreSQL Buildfarm is a global network of machines that continuously test PostgreSQL across a wide range of operating systems, architectures, compilers, and branches. Over the past few years, I have created and maintained several buildfarm members, each with its own quirks and strengths. In this post, I’ll share a status-update working on the following animals: alligator, dodo,

The PostgreSQL Buildfarm is a global network of machines that continuously test PostgreSQL across a wide range of operating systems, architectures, compilers, and branches. Over the past few years, I have created and maintained several buildfarm members, each with its own quirks and strengths. In this post, I’ll share a status-update working on the following animals: alligator, dodo,

In the past few months, two new database videos were released on YouTube. From Hollerith to Stonebraker, from IMS to Postgres, the first video does a great job of walking through the history of databases in a way that I have never seen before.

With 3k slides and 64 presentations (and more two pending), the Presentations section of my website was getting cluttered. (Okay, I guess it has been cluttered for a while.) I have restructured the sections, adding two, removing one, and moving superseded presentations to Old. Hopefully this will help website visitors more easily find useful information.

One of the temptations database users face, when presented with a huge table of interesting data, is to run queries that interrogate every record. Got a billion measurements? What’s the average of that?!

One way to find out is to just calculate the average.

SELECT avg(value) FROM mytable;

For a billion records, that could take a while!

Unlike the standard multi-node Postgres replication cluster, when managed by Patroni, all failovers are automatically executed. However, this is not the case when dealing with inter-datacentre failovers when for instance a standby datacentre must take over from a failed primary. The following describes the mechanisms required to perform such a procedure when the case arises. […]

On Tuesday, we had our last meetup of 2025, and we want to thank everyone who attended, and who supported us during 2025. An of course, very special thanks to Jay Miller, who present at both our first and last meetups! Everyone enjoyed the presentation, as well as pre-and post-conversations and pizza! Here as the presentation slides (Jay, thank you for sharing!):

The beautiful Old College building at the University of Edinburgh. Photo by LWYang from USA (CC BY 2.0).

I'm thrilled to announce that the PostgreSQL Edinburgh meetup is finally here! 🐘

Is your PostgreSQL database Feeling Sluggish? Are SQL statements taking more time than in earlier days? Are you experiencing performance cliffs (Unexpected, sudden drops in performance)? Are backups taking a long time to complete? Are you getting a bigger bill for storage? Are standby rebuilds and development refreshes becoming a herculean task? Are the auditors […]

Postgres 18, released on September 25, 2025, introduces an exciting set of performance improvements and new capabilities. Postgres has grown remarkably over the years, and with each major release has become a more robust, reliable, and responsive database for both mission critical and non-mission critical enterprise applications. I’ve been writing about these enhancements since the release, and today I’m diving into two more features that are especially useful in real-world applications.

When creating data models in PostgreSQL (or any other powerful relational database), several common problems can arise that hinder effective database design. One frequent issue is the incorrect normalization of tables, leading to redundant data, inefficient querying capabilities, or even simply plain wrong semantics. 

This post addresses one of the most common mistakes made by people new to the subject: Over-optimistic normalization. Especially developers relying too heavily on AI-generated data models are known to face this issue.

I recently watched a video about Starbucks and how their third place concept made them successful, and how their abandonment of it has caused problems. I started to realize that Postgres conferences also function as a "third place" — not home, not work, but somewhere people gather to see see old faces, new people, and to talk.

Everyone’s freaking out about AI taking their jobs. Meanwhile, I’m a DBA sitting in the corner thinking: “If programmers of the future are AI agents, companies will need 100x more human DBAs to clean up the mess in production.”

This rant blogpost is my attempt to explain why.

LLMs: Optimizing for the Next Token, Not for Reality

Let’s start with the core problem: