This article was a bit harder to write than it would seem on the surface. Amid all the hustle and bustle of the current development cycle, it was hard to find a particular focus of what this effort was all about. Then it finally dawned on me. There wasn’t one.

That may sound a bit harsh for the developers working on it, but please let me explain. PostgreSQL is caught in the middle of a maelstrom. As it continually tries to grow up, the meaning of being a grown up keeps changing.

Over the last 20 years, we have seen NoSQL, data warehousing, reporting, and telemetry applications completely change the playing field. We have also seen advancements in indexing and retrieval, file systems, and memory management. The hardware underneath PostgreSQL has changed several times, not to mention virtualization and cloud operation. Of course, this isn’t an exhaustive list, but you get the idea.

The rate of change has been so astounding that it beggars the imagination that the team has been able to keep up with it for so long. And it’s not slowing down any in the near future. There is quite a long laundry list of things that the community keeps asking about.

The PostgreSQL development group has responded to all those changes as fast as possible. They created better monitoring, better management, more locking for less blocking, and revamped processes to be more cooperative and generally increased performance to keep up with the demand.

The PostgreSQL 14 release is a continuation of that effort. I was hoping for a super shocking title like “PostgreSQL no longer needs VACUUM!”. That would have been awesome for search results and response. What I really got was “a lot of people made a huge effort to improve most of the things that needed improving.” Not quite the shocker that drives searches, but not to be underestimated in value.

Like any other teenager, these improvements are in search of what PostgreSQL is going to be someday. Improvement because this is the stage of life PostgreSQL is in, not because it is particularly driving anywhere.

Performance Improvements in PostgreSQL 14

The biggest single feature to point out is the connection handling at peak capacities. PostgreSQL has dramatically improved for connection counts above 5000. The pgAnalyze guys have a nice article about that.

Things that now take advantage of background processes to do it in parallel:

  • REFRESH MATERIALIZED VIEW
  • RETURN QUERY
  • Queries to foreign data wrappers

Improvements to CONCURRENTLY:

  • ALTER TABLE DETACH PARTITION CONCURRENTLY FINALIZE
  • Allow index commands using CONCURRENTLY to avoid waiting for the completion of other operations using CONCURRENTLY
  • CREATE INDEX CONCURRENTLY and REINDEX CONCURRENTLY no longer limit the dead row removal of other relations.

I would be remiss not to mention VACUUM improvements. These improvements are all under the hood, but this is one of the areas of improvement most needed by the community.