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[...]

file_extend_method is an escape hatch wearing the costume of a tuning knob. It exists for one purpose: to let you turn off a PostgreSQL 16 optimization on the filesystems where that optimization turned out to misbehave. When a table grows, PostgreSQL has to extend its data file, and there are two…

Building the OAPE PostgreSQL Certification

I’m one of the founders of the Open Alliance for PostgreSQL Education (OAPE).

Over the past two years, I’ve had a front-row seat to watching an idea become a community, and a community become a movement.

This is the story of how the idea of an open, vendor-neutral PostgreSQL certification turned into an organisation supported by contributors from around the world.

The classic “What If” — thought

There are moments when an idea seems so obvious that you wonder why it doesn’t already exist. Then you start digging into the details and realise why nobody has built it yet.

In spring 2024, I was sitting over a coffee with Jan Karremans. Nothing unusual. But this time, our conversation about PostgreSQL drifted towards certifications.

There was one question hanging in the air and dominating the conversation: “There is no independent PostgreSQL certification available — right?”

And it led to another: “What would it take to build one?” (a classic “What If”-question :D)

At the time, I hadn’t contributed much to the PostgreSQL community. Coming from the corporate world, I was still learning how open source works. Companies have budgets, dedicated teams, project plans, and management. Community initiatives are different. They exist because people decide something is worth building and over time, I learned something that now seems obvious: community projects don’t simply appear. They exist because people invest their evenings, weekends, and energy into creating something that benefits other people.

2024 was a real eye-opener for me as. Somewhere along the way, I realised I had become emotionally invested in the community. It started to feel a little like looking after an extended family.

Looking back, that coffee marked the beginning of a very interesting journey.

Open source projects start with people

Ideas are easy. Finding the right people to turn an idea into reality is much harder.

A few months later, Jan and I met Di

[...]

Postgres Summit US 2026 (formerly: PGConf NYC) will take place September 30 - October 2, at Convene, in New York. EDB is joining the event as a sponsor at the Gold-level. Our team of Postgres experts, core contributors, and innovators have secured a stellar lineup of sessions through the Call for Papers. From cloud-native transformations to deep-dive database internals, we’re covering a wide range of topics. 

Here is a sneak peek of what EDB is bringing to the stage in NYC.

Strategy & Architecture

Postgres adds roughly 200 features and improvements every year, yet a few major milestones remain

On 15 July 2026, the Prairie Postgres Meetup Group met, organized by Henrietta Dombrovskaya and Carlos Aranibar.

Speakers:

• Zach Paden
• Anna Bailliekova

On 18 July 2026, Alicja Kucharczyk, Pavlo Golub, Denys Holub & Anastasia Golub staffed the PostgreSQL booth at WAWTech Summer.

The PostgreSQL Madagascar Conference 2026 took place on 18 July 2026.

Organizers:

• BAOVOLA Marie Anna
• Dominique RAKOTONIRINA
• RAVAKINIAINA Tokifanantenana

Program Committee:

• Bodo Arivola
• Jerson Raheriniaina
• Toky Fandresena MANOVOSOA
• Vahatra

Speakers:

• Fabian Kimambo
• Lova Andriarimalala
• damien clochard
• Hans-Juergen Schoenig
• Nicaise CHOUNGMO FOFACK
• Prafulla Ranadive

Claire Giordano and Aaron Wislang hosted and published a new podcast episode on 17 July, 2026 “Working on Postgres after 13 years on SQL Server with Panagiotis Antonopoulos from the Talking Postgres series.

On 8 July, Evangeline Cheng delivered a talk at the PUG NYC, organized by Miaolai Zhou and Mason Sharp

Community Blog Posts:

• Jimmy Angelakos about PostgresEDI July 2026 Meetup — Public Speaking, AI Compliance
• Henrietta Dombrovskaya about Prairie Postgres July Meetup: Proudly Sourced at Midwest!
• Monica Oyugi about PGConf.dev 2026: Vancouver Showed Up and So Did I

Time, Physics, Mathematics, and Databases

Physics treats time as one of the fundamental dimensions of the universe. Mathematics transforms time into measurable values, equations, intervals, and limits. Databases quietly preserve time as operational reality. Every login, transaction, API call, backup, audit event, financial transfer, and monitoring alert depends on accurate timestamps. Modern computing runs on time far more than most people realize. 

A cloud-native application serving millions of users every day continuously tracks:

• login sessions,
• token expiry,
• replication timelines,
• backup retention, 
• audit histories,
• scheduled jobs,
• distributed events,
• cache expiration,
• monitoring alerts,
• certificate validation etc.,

Every one of these operations depends on timestamps behaving correctly. Most developers never think deeply about timestamps because modern systems usually make time feel invisible. A timestamp appears as a simple date in logs or dashboards. Underneath that simplicity, operating systems and databases continuously calculate time mathematically.

Many Unix-like systems calculate time as the number of seconds passed since:

1 January 1970

00:00:00 UTC

This reference point became known as the Unix Epoch.

At the time, this design looked practical, elegant, and efficient. Nobody expected that decades later engineers would still discuss the consequences of that decision while running AI workloads, distributed systems, Kubernetes clusters, and global cloud infrastructure.

The Integer That Quietly Controls Time

The Year 2038 problem begins with a mathematical limitation. For years, many systems stored timestamps using signed 32 bit integers. Signed integers can store both positive and negative numbers, but they also have a fixed range.

A signed 32 bit integer can store values from:

-2147483648 to 2147483647

The maximum positive value becomes extremely important because Unix-like systems count time forward

[...]

PostgreSQL 18's `file_copy_method = clone` can copy a terabyte database in half a second on copy-on-write filesystems. Here's when and why you should use it.