Sammlung von Newsfeeds

A lot of the time in database land, our queries are I/O constrained. As such, performance work often involves reducing the number of page reads. Indexes are a prime example, but they don’t solve every issue (a couple of which we’ll now explore).

Securing sensitive data requires more than just a firewall; let's see how Oracle implements VPD and PostgreSQL implement Row and Column level security

How ParadeDB uses principles from search engines to optimize Postgres' Top K performance.

Bluebox Docker provides a realistic, continuously-updating sample database for PostgreSQL users. It automates data generation, simulating a video rental kiosk with real movie data. Users can easily set it up with a single command, facilitating learning and practice of PostgreSQL features without dealing with stale data.

Only ONE WEEK LEFT for the earlybird tickets. Make sure you get yours before it's too late!

https://2026.pgday.paris/registration/

This was a long requested server side feature that have been committed recently to PostgreSQL core to inform users that their passwords must be changed before the expiration limit.

A new entity in the PostgreSQL landscape.

Introducing mnemosyne systems

The last week a new entity appeared in the PostgreSQL landscape: **mnemosyne systems **, the last creation of Jesper Pedersen.

The initial page says it all:

The short answer is always “maybe”. However, in the following post, I hope to demonstrate what creates a sub-transactions and what happens to the overall transaction id utilization when they are invoked. I will also show how performance is affected when there are lots of connections creating and consuming sub-transactions.

First, it is important to understand what statements will utilize a transaction id and which ones may be more critical (expensive) than others:

The PostgreSQL ecosystem just introduced a new pg_stat_plans extension. It's similar to pg_stat_statements but it tracks aggregated statistics for query plans instead of SQL statements.

Large language models know a remarkable amount about PostgreSQL. They can write SQL, explain query plans, and discuss the finer points of MVCC with genuine competence. But there are hard limits to what any model can know, and when you're building tools that connect LLMs to real databases, those limits become apparent surprisingly quickly.The core issue is training data. Models learn from whatever was available at the time they were trained, and that corpus is frozen the moment training ends.

Thanks to Boris Novikov, who pointed me in the PAX direction in the first place and followed up with many insightful technical discussions. I’m grateful for all his time and the great conversations we’ve had—and continue to have. I’ve been obsessed with database storage layouts for years now. Not the sexy kind of obsession, but the kind where you wake up at 3 AM thinking “wait, why are we loading 60 useless bytes into cache just to read 4 bytes?

The PostGIS development team is pleased to provide bug fix releases for PostGIS 3.0 - 3.6. These are the End-Of-Life (EOL) releases for PostGIS 3.0.12 and 3.1.13. If you haven’t already upgraded from 3.0 or 3.1 series, you should do so soon.

PGBLR Meetup met on February 7, organized by Organizers Amit Kapila, Kuntal Ghosh, Sivji Kumar Jha and Vigneshwaran C.

Speaker:

• Shreya R. Aithal
• Suresh
• Y V Ravi Kumar

Mumbai PostgreSQL UserGroup met on February 7 - organized by Ajit Gadge, Sovenath Shaw and Deepak Mahto

Speaker:

PostgreSQL uses a process-based architecture where each connection is handled by a separate process. Some data structures are shared between these processes, for example, the shared buffer cache or the write-ahead log (WAL). To coordinate access to these shared resources, PostgreSQL uses several locking mechanisms, including spinlocks. Spinlocks are intended for very short-term protection of shared structures: rather than immediately putting a waiting process to sleep, they busy-wait and repeatedly check whether the lock is free.

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.

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!

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.

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.

Saw this post on LinkedIn yesterday:

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: