The PostgreSQL Performance Farm is still not quite a reality, but I think there is some hope on the horizon.

After some discussions with various folks at AWS about large scale OLTP testing with PostgreSQL on EC2, I was introduced to Farrah Campbell last spring who has been helping open source software maintainers.  She hooked me up with some credits that I used to sign up for Kiro Powers.  It's been quite a while since I have done any significant performance testing and the OLTP test kits we developed back in the OSDL days could use some updating, in particular this DBT-5 kit.

Shortly after that, I caught up with Mila Zhou about the AWS Open Source Credits Program because doing any large scale OLTP testing in the cloud is going to take a serious amount of credits.  As luck would have it, I was granted enough credits to start working on sizing up a system.

I'm currently thinking a TPC-E-like workload might be a good stress test for PostgreSQL on EC2 with its more balance i/o to processing requirements compared to a TPC-C, so I've started sizing up a r5b.4xlarge instance type with as many block devices as it can attach to

Keep an eye out here and on Blue Sky as I start posting updates over the coming weeks.

On 16th of March 2026, Peter Eisentraut committed patch: SQL Property Graph Queries (SQL/PGQ)   Implementation of SQL property graph queries, according to SQL/PGQ standard (ISO/IEC 9075-16:2023).   This adds:   - GRAPH_TABLE table function for graph pattern matching - DDL commands CREATE/ALTER/DROP PROPERTY GRAPH - several new system catalogs and information schema views - … Continue reading "Waiting for PostgreSQL 19 – SQL Property Graph Queries (SQL/PGQ)"

I'm pleased to announce that David Rowley will be joining us in September to discuss his talk Optimizing code in the hot path; with examples from tuple deformation. If you're interesting in joining us, please sign up using this form and I will send you an invite to one of the sessions. As always, thanks to David for agreeing to join the sessions.

Read more »

PostgreSQL 18 adds a Grand Unified Configuration (GUC), , that lets an extension's control and SQL files live outside the server's own directories. Together with Kubernetes's ImageVolume and Docker's , that makes it practical to package an extension as its own small OCI container image and mount it into the PostgreSQL pod at runtime, without rebuilding the server image.The idea is compelling. A fleet of clusters sharing one lean, unmodified PostgreSQL image. Extensions versioned and upgraded independently. pgvector 0.8 today, 0.9 tomorrow, without touching the server layer - sounds clean.It is clean - for the right extensions. For others, the container boundary doesn't actually decouple anything meaningful. Whether the extension deserves its own container depends almost entirely on how deeply it is wired into the server's startup sequence, process tree, and storage subsystem. This post maps out that landscape.

What PostgreSQL 18 Actually Changed

Before PostgreSQL 18,  already let you place shared libraries (. files) outside the compiled-in . While  took care of the binary side of an extension, the gap was the control side: extension control files (.) and SQL scripts had to live in  with no override mechanism. Any extension that wasn't installed in the server's own share directory simply could not be found by .PostgreSQL 18 closes that gap by adding  - a GUC that works exactly like  but for control and SQL files. Set both GUCs together, and an extension can live entirely outside the PostgreSQL installation:One subtlety that tripped us up during testing:  takes sharedir-level paths, not the extension subdirectory directly. PostgreSQL appends  automatically when scanning for .control files. Specifying the full path to the extension subdirectory silently finds nothing, not even built-in extensions like plpgsql.The  placeholder resolves to the compiled in sharedir (the path returned by ). It must appear in extension_control_path or the server loses access to all its own built-in extensions. The same logic appli[...]

The official logs are still processing, but the raw data is ready.

Welcome to the newest #UNLOGGED drop from WAWTech+Summer 2026 in Warsaw. We traded the classic conference center for an open-air tech festival at Tor Służewiec, and the energy was incredible.

This uncompressed cut captures the pure hallway track reality—setting up the Postgres booth with the international team, taking the stage for my talk on “From Hops to Vectors: Building AI-Powered Beer Recommendations in Postgres,” and the inevitable post-event fast food run.

Skip the WAL. Enjoy the raw feed. Link to the full video on YouTube.

Postgres ships with a genuinely bountiful catalog of built-in functions. There are literally thousands of them, covering everything from trigonometry to JSON path queries to full-text ranking. It's a kitchen sink of staggering proportions. Somehow despite all of that, there are actually still a few gaps to fill.Need a random date for some test data? That's going to be an entire expression, I'm afraid. How about the exact definition of a role, tablespace, or database? You better have a GUI database tool like pgAdmin or access to the  command with a little assistance from .It's little annoyances like this that Postgres 19 aims to alleviate. Let's explore these new quality of life enhancements!

In the Near Future

Suppose we want a random date sometime in 2026. The canonical approach for this has been to begin with January 1st and add a random amount of days:It's kind of a hack, but it works. Aside from not accounting for leap years, there's also something else to take note of:We asked for a date and got a , because adding an interval to a date promotes the whole expression. If we actually wanted a , we have to wrap the result in another cast. If we wanted a , that's a different cast. That's not exactly critical, but type sensitivity varies across platforms.Either way, that's a lot of ceremony for "give me a random date."So Postgres 19 adds a family of  overloads that take an explicit lower and upper bound. The  we all know and love is still around in the mathematical functions, but now there are three new temporal definitions in datetime functions.There's one for each of the valid Postgres date and time types:A random date is now just , and the result is a real . No interval multiplication, trailing cast, or surprise timestamp conversion. Ditto for  and . The inclusive bounds also address the issue we had with leap years, where adding 364 days could mean never reaching December 31st.You may have also noticed the matching significant figures in the  output. If you haven't ever used that before, it works univer[...]

PostgreSQL's hot_standby switch transforms a spare server into a readable replica, but the real tuning work happens elsewhere.

Most production vector queries are not simple nearest-neighbor searches. Rarely is the query to return "the 10 most similar documents in the entire table." Typically, it's something closer to: find the 10 most similar documents in the legal category, published in the last 30 days. That mix of similarity ranking plus scalar filters is hybrid search.

We have written before about HNSW indexes with pgvector and scaling vector data. Those posts go over indexes used to accelerate Nearest Neighbor queries with Approximate Nearest Neighbor indexes (ANN indexes). The next problem shows up the moment a WHERE clause is added. pgvector's iterative index scans help with filtered search, but they come with some tuning and tradeoffs.

When nearest neighbor meets a WHERE clause

Here is the query almost everyone writes first:

SELECT id, content
FROM docs
WHERE category = 'legal'
ORDER BY emb <=> '[0.031, ...]'
LIMIT 10;

It looks innocent. With a typical B-tree index, a WHERE plus ORDER BY is a solved problem: the planner picks an index, applies the filter, sorts what is left, and you move on.

A vector index finds nearby embeddings; a WHERE clause filters rows. Combining them forces Postgres to sacrifice either recall or performance.

The natural follow-up question is: why not just intersect the indexes? Postgres already knows how to combine two B-trees. Scan each index, build bitmaps of matching row IDs, BitmapAnd them together, and done. If you have an index on category and an index on emb, why can't the planner find the rows that are both legal and near the query vector the same way?

Because the two indexes are not answering the same kind of question.

A B-tree on category returns a set. The predicate category = 'legal' is a yes-or-no membership test. Every qualifying row ID goes into the set. That shape is perfect for intersection: set of legal rows, set of active rows, or tenant = 42, or (you get the point).

An HNSW (and IVFFlat) index returns an approximate ordered top-k, not a set. ORDER

[...]

High availability setups are never “set and forget”. Every new release of your tooling can change how your cluster behaves at 03:00 when something breaks.

vip-manager v5 is one of those releases you really want to read about before just hitting apt upgrade. In this post I’ll walk through the important breaking changes, what they mean in practice, and what you should do before rolling this out on production.

---

Quick reminder: what vip-manager does

vip-manager is the small helper that manages a Virtual IP (VIP) in front of your PostgreSQL primary:

• It watches the Distributed Configuration Store (DCS) / leader info (patroni, etcd, Consul, ZooKeeper, etc.).
• When a node becomes leader, vip-manager attaches the VIP to it.
• When it loses leadership, vip-manager removes the VIP.

Clients connect to the VIP, not to the individual node. If the VIP is wrong or stale, your applications hit the wrong PostgreSQL instance. That’s why these behavior changes matter.

---

Breaking change #1: configuration refactor

The configuration handling in vip-manager v5 has been refactored and deprecated parameters have been removed.

In other words: if you still rely on old, deprecated keys in vip-manager.yml, v5 may fail to start or behave differently than you expect.

What you should do

Before upgrading:

1. Open your config
   Check your current vip-manager.yml on all nodes where vip-manager runs.

2. Compare against current documentation
   Use the v5 docs or sample config and line them up with your file.

3. Remove deprecated parameters
   Any parameter that is no longer recognized must go. Do not assume “it will just ignore it” — future refactors often get stricter.

4. Rename to current keys
   Where keys have been renamed, update to the new names instead of keeping legacy aliases.

If you keep your configs in Git (you should), this is a good moment to commit a clean, documented vip-manager.yml so that

[...]

hba_file points to your authentication rules, not the rules themselves. Reload changes to pg_hba.conf instantly; restart when moving the file.

What Is Open Alliance for PostgreSQL Education (OAPE)?

The OAPE is the recently founded organistion that will offer indipendent community PostgreSQL certifications.

Why Becoming A Supporter

For years there have only been companies offering PostgreSQL certifications.

I always believed, that the PostgreSQL community could do better with community based certifications.
A community based certification has the advantage, that even the process itself becomes public.

The program needs people doing the work and to create the exams and the certifications.

First Chance To Become A Certified PostgreSQL DBA

The PostgreSQL Conference Europe 2026 has an addition Community Day. On this day the OAPE offers the PostgreSQL Open Certification Level: DBA-1.

You have to register yourself for the Community Day to get certified on that day. For details please see OAPE Meetup and the Exam.

 DBeaver recently introduced interactive chat capabilities into the free, open-source Community Edition. What does that mean? 

It means some of your database tasks can be accomplished significantly faster! 

First, you can ask for information without coding SQL. I love Structured Query Language, but it is much faster to write this prompt:

What are the top ten most popular rentals and how much revenue did they generate?

[...]

Background

I've been working on pgjdbc, the PostgreSQL JDBC driver, for many years. It's a great driver, gets millions of monthly downloads, and it's not going anywhere.

It's also a driver whose shape was decided a very long time ago. JDBC came first and PostgreSQL came second. The JVM it was designed for had no virtual threads, no records, and no sealed types. Most of what you'd want to change about that today can't be changed in place. Doing so would break the applications that depend on the current behavior, and that's most of the Java world talking to PostgreSQL.

So I started a new one: pg-java.

It's a modern, PostgreSQL-specific driver for the JVM, and it is pre-release. But the core driver works, there's a JDBC layer on top of it, and it's been tested far more thoroughly than "pre-release" usually implies.

Why a new driver

Four things drove the design.

PostgreSQL-first. The native API is designed around PostgreSQL's wire protocol and feature set. It is not designed around the lowest common denominator that JDBC has to support across every database on earth. If PostgreSQL can do it, the API should be able to say it directly.

JDBC as a layer, not a foundation. Full JDBC compliance is a long-term goal. There's already a java.sql.* layer that registers a Driver and gives you Connection, PreparedStatement, ResultSet, DatabaseMetaData,

[...]

Hash and sort operations have wildly different relationships with memory, and `hash_mem_multiplier` lets you feed them separately.

Seven major versions of PostgreSQL shipped between 2018 and 2025, one per year without exception, and each with a changelog of 150 to 200 user-visible changes. Each release covers a broad canvas — performance, replication, administration, and security — but every one of them also advanced the SQL layer, filling gaps in the standard, adding missing functionality, or cleaning up long-standing rough edges. Working through the new edition of The Art of PostgreSQL forced me to catalogue them all; this is my selection of the features I kept reaching for while rewriting the examples. I hope it’s useful beyond that context — organized by theme, with the version each feature landed in.

To get a sense of where the community actually puts its effort, Noriyoshi Shinoda of Hewlett-Packard Enterprise Japan has been publishing a meticulous “PostgreSQL New Features with Examples” series for every major release since version 9.4 — each edition catalogues every user-visible change with a working code example. Counting his categories across PG 11–18 gives a clear picture of contributor priorities:

Release	SQL	Performance	Admin & Ops	Replication	Security	Other
PG 11	5	6	5	3

[...]

Picture this: it's Monday morning, your coffee is still warm, and someone from finance slides into your DMs asking why the Q4 revenue number doesn't match what they expected. You know the data flows through about five transformation steps, but the pipeline was built by someone who left two years ago, and the documentation is... let's say aspirational.

So you do what any engineer does: you start digging. You grep through ETL scripts. You trace foreign keys. You find a view that references another view that references a table that might have been renamed at some point. An hour later, you're not sure if you've found the answer or just found more questions.

This is the data lineage problem. And if you've been around data systems long enough, you've lived it.

What even is data lineage?

Let me give you the textbook definition first, then I'll translate it into something that doesn't make your eyes glaze over.

Data lineage is basically a paper trail for your data. It answers:

• Where did this come from? (Provenance - the what and where of your data's origins)

• What else depends on this? (Dependency - the blast radius of a change)

• What happened to it along the way? (Transformation history - the mutations it went through)

• If I change this upstream, what breaks? (Impact analysis - the "oh no" question)

Think of it like a family tree, but for your data. Every value has parents (the data that created it), grandparents (the data that created the parents), and so on back to the original source. And like family trees, it gets complicated fast once you go back more than a couple generations.

Why should you care? (Besides "it's the right thing to do")

Here's where it gets real. Regulations actually require this stuff:

• GDPR Article 5(2) - remember that one? It says people have the right to understand "the logic involved" in processing their data. You can't explain the logic if you can't trace where the data went.

• SOX - if you're in

[...]

PostgreSQL 16 lets servers accept delegated Kerberos credentials to act as users against other services, but it defaults to off because the trade-off is real…

Why Enterprise Platforms Often Fail Long Before They Break

The examples in this article are anonymized, and certain details have been adjusted to protect the organizations involved.

---

The Crossroads Nobody Schedules

Every enterprise platform eventually reaches a crossroads.

Not because it stops working. Because it slowly becomes harder to change.

The warning signs almost never arrive as outages. They arrive as hesitation.

Upgrades get postponed to the next quarter, and then the quarter after that. Deployment windows stretch from two hours to six. Recovery exercises get scheduled, then quietly moved. Architects begin designing around the platform instead of with it — a new service here, a side database there, an integration layer that was only ever meant to be temporary.

And then someone in a design review says the six words that should concern every technology leader:

“Let’s not touch that.”

Nothing appears broken. Availability is excellent. The dashboards are green. Leadership believes the modernization succeeded, and by every metric on the executive dashboard, it did.

Yet confidence has quietly begun to disappear.

Across banking, insurance, telecom, and healthcare, this is how most enterprise platforms actually accumulate risk. Not through catastrophic failure. Through the gradual erosion of trust. The platform doesn’t collapse — it calcifies. And calcification is more expensive than an outage, because an outage ends and calcification compounds.

That observation is what led me to develop the CALM Platform Test.

Not another maturity model. Not another operational checklist. A way of answering a question most organizations never think to ask:

Does this platform become easier to trust as it grows?

That question has become urgent in a way it wasn’t five years ago. We are placing AI workloads — retrieval, embeddings, agents, workflows that take action on behalf of the business — on top of platforms that were never evaluated for their capacity

[...]

The first thing you will probably learn about Postgres, if you follow people who don't like Postgres, is that MVCC is bad. The 40-year-old design mistake. It's signatures are everywhere. Bloated tables that double in size, 32-bit transaction counter limit, the never ending struggle with VACCUM, dead tuples nightmares. It comes with credentials, too: Uber measured the write amplification in 2016 and left for MySQL over it; Andy Pavlo's database group called MVCC the part of PostgreSQL they hate the most. It's a real thing. Postgres is as bad as it gets.

While none of this is exaggerated, it comes down to a real design choice. The bloat, the amplified writes, the vacuum babysitting: every charge traces to a decision, not a defect, and we reproduce each one below on a live PostgreSQL 19 beta2 instance, so you can watch the damage happen yourself. But the verdict that spreads from community to community always stops one question early: compared to what? What does every other engine do instead, and what does that cost?

Because MVCC is not optional. Any database that wants readers to not block writers has to keep multiple versions of rows somewhere, and every engine that does so answers the same four questions:

1. Where do old versions live? In the table itself, or in a separate structure?
2. Which way do version chains point? From old to new, or new to old?
3. What do indexes point at? A physical row location, or a logical key?
4. Who cleans up, and when? A background process later, or the transaction itself?

PostgreSQL's answers: in the table, old to new, physical location, background process later. Every cost the critics list follows from those four answers. And every alternative is a different set of answers with the bill sent to someone else, the writer, the reader of history, tempdb, the cache, the compactor. One of them spent years of engineering to buy the one property PostgreSQL's design has had for free since day one. All of them fail, differently, when a transacti

[...]

PostgreSQL's `gin_fuzzy_search_limit` silently returns a random subset of matching rows instead of all results—a dangerous trade of correctness for speed that…

At a Postgres meetup in Melbourne, I finally got a straight answer to a question that had nagged me for quite a long time: why do people actually choose Postgres? It isn't an idle question for me — I spend my days reading field reports and designing planner features, and keep seeing how much smarter some other databases are. The gap has narrowed drastically over the last ten years, but even now some SQL Server techniques still execute certain queries much faster.

The answer I got was disarming: 'Postgres is just good enough for our purposes.'

Think about what that means. Open source, no vendor lock-in, and you can always find someone who knows the codebase and can reliably fix a problem or scale the load. Good enough beats brilliant. Significant part of database systems market doesn't care about superiority — they want simplicity, maintainability, predictability, and reliability.

That sounds like a trivial observation. It isn't — not if you are the one trying to get a new, pioneering, sometimes provocative feature into Postgres core.

The uncomfortable logic

Postgres holds mission-critical data, so efficiency and scalability are only second- or third-order concerns. And no code is free of bugs: every line you add is a new bug and a maintenance liability the whole community inherits. So the bar is brutal, and it applies in this order — your feature must first prove safety and the absence of regressions, then provide documentation, and only after all that does the gist of the idea finally get to take the stage. A feature survives that gauntlet only if users are already hurting for it: if you can show they genuinely struggle with a problem it solves.

If your instincts were formed between 2000 and 2015, when people boldly shipped massive, breakthrough features, this comes as a revelation. And if you just want an easy commit to prove your database technology, Postgres core is the wrong venue — pick a project where stability matters less, probably something from the OLAP area.

So what do y

[...]

AWS was kind enough to organize an AI workshop this week in Pittsburgh for their employees, and the Postgres committers and core team. The first day covered the basics of setting up Claude and specifically how to use it from the command line to analyze files and automate workflows. We also discussed how AI-automated workflows can do testing, benchmarking, and create proof-of-concept patches to explore ideas that were previously too complex or time consuming to consider.

On the second day, we did hands-on setup of Claude Code, and discussed how we can modify and add things to our source tree to improve AI usage. We also discussed how to improve our workflow in analyzing email threads and reviewing patches. On the final day, we picked various bug reports and used AI to improve email thread analysis and patch review. I found the event very relaxing, like a tech retreat, and hope we can do something like it again.

PostgreSQL's genetic query optimizer has seven knobs, but you should probably only touch one. Learn which one, and why the others are best left alone.

Why PostgreSQL logs entire pages after crashes and why turning it off is riskier than it sounds.

The autovacuum process has been dutifully tending Postgres tables since version 8.1, and almost every release since has acquired some new refinement: smarter thresholds, insert-aware triggering, resource cost limits, and so on. It's the reliable maintenance workhorse that heroically forestalls transaction ID wraparound and keeps statistics fresh. So how did the devs improve it this time around?For most of its life, an autovacuum worker built its list of tables needing attention and then worked through them in roughly the order they appear in the  catalog. Very egalitarian. But a table one transaction away from triggering a wraparound shutdown got the same treatment as a table that crossed a statistical update threshold. Any implied urgency is lost in that context. So how do you teach a maintenance daemon the difference between sweeping the floor and putting out a five-alarm fire? Can an administrator dictate that the cluster cares more about freezing rows than reclaiming space without rewriting the whole scheduler? There's only one way to find out!

Keeping Score

The mechanism behind the change is a prioritization system that scores every table before the worker decides where to start. The launcher picks a database first, favoring any database skirting transaction ID or multixact wraparound, then deferring to whichever went longest without attention. Within that database, the worker builds its candidate list and sorts it by a numeric score instead of catalog order.That score is a weighted heuristic. Postgres computes five separate component scores for each table and keeps the highest as the table's overall priority. The components are the transaction ID age, the multixact ID age, the count of dead tuples waiting to be reclaimed, the count of freshly inserted tuples, and the volume of changes since the last . Whichever of those is highest decides the table's place in line.We don't have to take any of this on faith, because Postgres 19 also exposes a new pg_stat_autovacuum_scores view that reflects the curren[...]

fsync defaults to on and is the most dangerous setting in postgresql.conf—set it wrong and you risk unrecoverable data corruption, not just bad plans.

[...]

Subqueries in FROM clauses get flattened into the outer query by default—but only if the resulting join problem stays small enough.

In my previous blog on the pgEdge Vectorizer and RAG Server, I showed how to build a semantic search pipeline using dense vector embeddings. The RAG Server already did hybrid search, combining vector similarity with BM25 keyword matching, but BM25 was handled at the application layer, not inside PostgreSQL.That changes now. The pgedge-vectorizer extension adds BM25 sparse vector generation directly into the vectorizer, running inside PostgreSQL alongside the dense embeddings. Results are fused using reciprocal rank fusion (RRF). In this blog I will show you what this means in practice.I am using the same Rocky Linux ARM64 VM and testdb configuration from the previous blog: two pgEdge nodes, n1 on port 5432 and n2 on port 5433, using Ollama with nomic-embed-text. If you have not read that blog yet, start there first.

Why Hybrid Search?

To understand what this feature does, it helps to understand the three pieces behind it.

Dense Vector Search

When you run a semantic search, the extension converts your query and data into a list of numbers called a vector. These numbers capture meaning. Data that matches your query ends up with similar numbers, even if the words are completely different.That is why a query like "how do I get back into my account?" finds an article titled "Account Recovery" even though the query uses none of the same phrasing. The embedding model understands that getting back into your account and account recovery describe the same thing.Dense search is powerful for conceptual queries. Where it struggles is exact technical terms. Search for "wal_level = logical" and the model may rank a general replication article above the one that specifically explains that parameter, because it treats all replication content as semantically similar.

BM25

BM25 takes the opposite approach. It does not understand the meaning at all. It counts words.Specifically it scores documents based on two things: how often your query terms appear in a document, and how rare those terms are across your entire knowle[...]