Sammlung von Newsfeeds

Emma Sayoran organized a PUG Armenia speed networking meetup on December 25 2025.

FOSDEM PGDay 2026 Schedule announced on Dec 23 2025. Call for Paper Committee:

• Teresa Lopes
• Stefan Fercot
• Flavio Gurgel

Community Blog Posts:

• Chiira B. Mwangi I joined a community!

Recent changes in the software bundled in PgOSM Flex resulted in unexpected improvements when using OpenStreetMap roads data for routing. The short story: routing with PgOSM Flex 1.2.0 is faster, easier, and produces higher quality data for routing! I came to this conclusion after completing a variety of testing with the old and new versions of PgOSM Flex. This post outlines my testing and findings.

Graph databases have become increasingly popular for modeling complex relationships in data. But what if you could leverage graph capabilities within the familiar PostgreSQL environment you already know and love? In this article, I’ll explore how PostgreSQL can serve as a graph database using the Apache AGE extension, demonstrated through a fun use case: analyzing social connections in the craft beer community using Untappd data.

Introduction

I started contributing to PostgreSQL around 2020. This year I wanted to work harder, so I will explain the PostgreSQL features I developed and committed in 2025.

I also committed some other patches, but they were bug fixes or small document changes. Here I explain the ones that seem most useful.

These are mainly features in PostgreSQL 19, now in development. They may be reverted before the final release.

I found a copy of an interview that apparently has not been published anywhere



Interview with Oleg Bartunov


“Making Postgres available in multiple languages was not my goal—I was just working on my actual task.”

A couple weeks ago I posted about how setting maintenance_work_mem too high may make things slower. Which can be surprising, as the intuition is that memory makes things faster. I got an e-mail about that post, asking if the conclusion would change on a busy system. That’s a really good question, so let’s look at it.

To paraphrase the message I got, it went something like this:

The 1,600‑column ceiling, and the real production problems that show up long before it

If you’ve ever had a deployment fail with “tables can have at most 1600 columns”, you already know this isn’t an academic limit. It shows up at the worst time: during a release, during a migration, or right when a customer escalation is already in flight.

But here’s the more common reality: most teams never hit 1,600 columns; they hit the consequences of wide tables first:

Santa doesn’t judge your SQL by intent. Santa judges it by execution plans, logical io, cpu utilization, temp usage, and response time.

This is a practical conversion guide: common “naughty” query patterns and the simplest ways to turn each into a “nice list” version that is faster, more predictable, and less likely to ruin your on-call holidays.

PostgreSQL is highly suitable for powering critical applications in all industries. While PostgreSQL offers good performance, there are issues not too many users are aware of but which play a key role when it comes to efficiency and speed in general. Most people understand that more CPUs, better storage, more RAM and alike will speed up things. But what about something that is equally important?

We are of course talking about “latency”.

Have you ever watched long running migration script, wondering if it's about to wreck your data? Or wish you can "just" spin a fresh copy of database for each test run? Or wanted to have reproducible snapshots to reset between runs of your test suite, (and yes, because you are reading boringSQL) needed to reset the learning environment?

When your database is a few megabytes, pg_dump and restore works fine. But what happens when you're dealing with hundreds of megabytes/gigabytes - or more? Suddenly "just make a copy" becomes a burden.

Pavlo Golub gave a talk at WaW Tech conference in Warsaw on Dec 16 2025

Hyderabad PostgreSQL UserGroup Meetup on Dec 19 2025. Organised by Hari Kiran.

Speakers:

Earlier this year we started a program (“Developer U”) to help colleagues who show promise for PostgreSQL Development to become contributors.

This is an incident report, a post-mortem writeup and detailed info how we started supporting multiple RHEL minor versions.

Last month PostgreSQL RPM repos were broken for Rocky Linux and AlmaLinux 9 and 10 users due to an OpenSSL update that Red Hat pushed to versions 10.1 and 9.7, which broke backward compatibility. Actually I broke the repos. Continue reading "What happened?"

I compiled and uploaded zip files with latest orafce and plpgsql_check for PostgreSQL 17 and PostgreSQL 18 - I used Microsoft Visual C 2022.

Setup:

You’ve probably seen the incident pattern:

1. Postgres backends start disappearing.
2. dmesg / journalctl -k shows the kernel OOM killer reaping postgres.
3. Someone spots “out of memory” and reflexively recommends: “Increase work_mem.”

That recommendation is frequently backwards for OS OOM kills.

For years now pgAdmin builds on Windows have been code signed using a certificate installed on a build machine in AWS. That certificate is expiring, so I had to look for a new one (I no longer work at a company that supports Windows that can provide one), and much to my annoyance I found that requirements have changed and a secure physical device is required for key storage.

As AI capabilities continue to evolve and integrate more deeply into our applications, we’re faced with interesting architectural decisions about how to expose our data to large language models (LLMs). Two approaches that have gained significant traction are Retrieval Augmented Generation (RAG) servers (such as pgEdge RAG Server) and Model Context Protocol (MCP) servers (such as pgEdge Natural Language Agent).

As AI capabilities continue to evolve and integrate more deeply into our applications, we’re faced with interesting architectural decisions about how to expose our data to large language models (LLMs). Two approaches that have gained significant traction are Retrieval Augmented Generation (RAG) servers (such as pgEdge RAG Server) and Model Context Protocol (MCP) servers (such as pgEdge Natural Language Agent).

I like reproducible development. I also like short feedback loops. Combining both for pgrx was… educational. 🙂 In this post, I share the mistakes, the small pains, and the fixes I used to get a working VS Code dev container for a Rust project that builds PostgreSQL extensions with pgrx. If you’re writing extensions or using pgrx in a team, this will save you a few grey hairs.

TL;DR:

New post up on on the ClickHouse blog: