PostgreSQL *

A PostgreSQL service can keep processing almost the same number of requests per second while its slowest requests become several times worse. CPU may still look comfortable, query execution time may barely move, and throughput may remain almost flat. The problem can appear one layer earlier, inside the connection pool, where requests start waiting before PostgreSQL even sees them. This experiment shows how that happens and why p99 usually notices it long before RPS does.

My Go API benchmark once showed an almost 7x throughput improvement after I moved a read-heavy endpoint from PostgreSQL to a local in-memory cache. The result looked obvious: PostgreSQL was the bottleneck, the cache removed it, and the API became much faster. Later I realized that this interpretation was too simple. ApacheBench had measured an entire request path consisting of HTTP handling, connection management, pgxpool waiting, SQL execution, decoding, serialization, and response writing. I decided to decompose that path and understand what the 7x result actually meant.

Everyone loves security — until they have to configure it. The first version of our audit extension felt like a nuclear power plant control panel: infinitely flexible, but impossible to operate without a manual. We admitted defeat, listened to DBA complaints, and shipped version 2.0 — with event classes and configuration logic designed for humans, not just compilers.

This article tells the story of fixing our own mistakes and turning a “shelf-ware” product into a tool people actually use.

From 18 to 21 November 2026, Nepal will host PGConf.Nepal 2026, the country’s fourth PostgreSQL conference. The previous events took place in 2018, 2023, and 2025. This year, the conference is expected to bring together a wider mix of participants, organisations, and countries.

The journey from a single A100 in the cloud to an H200 cluster is not just a hardware upgrade — it’s a story of how an ML team stopped chasing “the one perfect model” and started building an ecosystem. When there are millions of lines of PostgreSQL C code under the hood and tasks range from hint-set generation to Graph-RAG, the model stops being a black box and becomes just another replaceable component. We explain how we rebuilt our stack around vLLM and MCP, why context management matters more than model weights, and how we made a 0.6B-parameter model perform on par with the giants using GRPO.

What do 1C queries, IN (VALUES ...) constructs, and the innocent expression x + 0 have in common? They can all turn a millisecond query into a multi-minute wait because PostgreSQL's standard planner "trips" over them. We break down how the pgpro_planner extension rewrites tricky parts of the query tree into a friendly form before the optimizer picks a bad plan — and why some of these fixes have already made it into vanilla PostgreSQL 18.

Imagine your heaviest SQL queries running in milliseconds. It sounds like science fiction, but with the pgpro_result_cache extension, it’s very real. In this article, we’ll look at how multi-second queries can be turned into lightning-fast cache hits.

Today I present results from the first step towards enabling temporary tables in PostgreSQL parallel query execution: benchmarking sequential writes and reads of temp buffers. I added functions to the PostgreSQL system catalog to measure buffer flush operations and ran a set of tests. For the planner, I estimated the cost coefficient of flushing a temporary table buffer page to disk relative to the existing DEFAULT_SEQ_PAGE_COST. I also estimated the cost of a simple scan of temp buffers (a dry-run). Measurements show that sequential writes are about 30% slower than reads. Based on these results, I propose a cost formula. I also ran a limited “dry-run” style estimate and measured write speed when table blocks are distributed across memory pages randomly.

There’s a dangerous illusion that “vanilla” open source is a silver bullet for enterprise systems. A real-world stress test of recent years has shown the opposite: when familiar giants like Oracle step aside, plain PostgreSQL often turns into a pumpkin under true enterprise workloads.

Mark Rivkin, Head of technical consulting at Postgres Professional, shares his personal perspective on why teams end up reinventing the wheel — adding millions of lines of code to the core — and why the future belongs to converged database systems.

Disclaimer: this article reflects the author’s independent expert opinion.

Continuing the series of CommitFest 19 reviews, today we're covering the January 2026 CommitFest.

The highlights from previous CommitFests are available here: 2025-07, 2025-09, 2025-11.

Partitioning: merging and splitting partitions
pg_dump[all]/pg_restore: dumping and restoring extended statistics
file_fdw: skipping initial rows
Logical replication: enabling and disabling WAL logical decoding without server restart
Monitoring logical replication slot synchronization delays
pg_available_extensions shows extension installation directories
New function pg_get_multixact_stats: multixact usage statistics
Improvements to vacuum and analyze progress monitoring
Vacuum: memory usage information
vacuumdb --dry-run
jsonb_agg optimization
LISTEN/NOTIFY optimization
ICU: character conversion function optimization
The parameter standard_conforming_strings can no longer be disabled

This article reviews the November 2025 CommitFest.

For the highlights of the previous two CommitFests, check out our last posts: 2025-07, 2025-09.

Planner: eager aggregation
Converting COUNT(1) and COUNT(not_null_col) to COUNT(*)
Parallel TID Range Scan
COPY … TO with partitioned tables
New function error_on_null
Planner support functions for optimizing set-returning functions (SRF)
SQL-standard style functions with temporary objects
BRIN indexes: using the read stream interface for vacuuming
WAIT FOR: waiting for synchronization between replica and primary
Logical replication of sequences
pg_stat_replication_slots: a counter for memory limit exceeds during logical decoding
pg_buffercache: buffer distribution across OS pages
pg_buffercache: marking buffers as dirty
Statistics reset time for individual relations and functions
Monitoring the volume of full page images written to WAL
New parameter log_autoanalyze_min_duration
psql: search path in the prompt
psql: displaying boolean values
pg_rewind: skip copying WAL segments already present on the target server
pgbench: continue running after SQL command errors

Your service has just published a message to RabbitMQ — and then, right at commit time, the database transaction rolls back. The classic distributed-systems nightmare: ghost data, broken consistency, and hours lost to debugging. Usually you fight this with tricky custom code, two-phase commits, or just… crossing your fingers. But what if a PostgreSQL rollback could automatically “roll back” the message too, putting it back into the queue without you writing a single extra line? Here’s how that works.

We continue our series of articles reviewing changes in PostgreSQL 19. This time we'll look at what emerged from the September 2025 CommitFest.

The highlights from the first July CommitFest are available here: 2025-07.

GROUP BY ALL
Window functions: NULL value handling
Event triggers in PL/Python
More precise error message for incorrect routine parameter names
random: random date/time within a specified range
base64url format for encode and decode functions
New debug_print_raw_parse parameter
The log_lock_waits parameter is now enabled by default
pg_stat_progress_basebackup: backup type
vacuumdb: collecting statistics on partitioned tables
Buffer cache: using clock-sweep algorithm to find free buffers
Fake table aliases in queries

We're launching a new series of articles covering the changes coming up in PostgreSQL 19. This first article focuses on the events from last summer's July CommitFest.

Connection service file in libpq parameter and psql variable
regdatabase: a type for database identifiers
pg_stat_statements: counters for generic and custom plans
pg_stat_statements: FETCH command normalization
pg_stat_statements: normalizing commands with parameter lists in IN clauses
EXPLAIN: Memoize node estimates
btree_gin: comparison operators for integer types
pg_upgrade: optimized migration of large objects
Optimized temporary table truncation
Planner: incremental sort in Append and MergeAppend nodes
Domain constraint validation no longer blocks DML operations
CHECKPOINT command parameters
COPY FROM: skipping initial rows
pg_dsm_registry_allocations: dynamic shared memory (DSM) usage

Page pruning (HOT cleanup) is an optimization allowing to efficiently remove old row versions (tuples) from table blocks. The freed space will be reused for new row versions. The only space occupied by row versions beyond the database's xmin horizon is reclaimed. This article examines the algorithm behind a similar optimization for indexes. If the xmin horizon is held back - by a long-running query or transaction - neither page pruning nor VACUUM can reclaim space, forcing new row versions to be inserted into different blocks. With the standard pgbench test, we demonstrate how significantly performance can degrade when the database horizon is held back, and we analyze the underlying causes. 

You’ve probably had this happen too: a service runs smoothly, keeps users happy with its stability and performance, and your monitoring stays reassuringly green. Then, the next moment — boom, it’s gone. You panic, dive into the error logs, and find either a vague segfault or nothing at all. What to do is unclear, and production needs saving, so you bring it back up — and everything works just like before. You try to investigate what happened, but over time you switch to other tasks, and the incident fades into the background or gets forgotten entirely.

That’s all fine when you’re on your own. But once you have many customers, sooner or later you start feeling that something isn’t right, and that you need to dig into these spikes of entropy to find the root cause of such incidents.

This article describes our year-long investigation. You’ll learn why PostgreSQL (and any other application) can crash because of a bug in the Linux kernel, what XFS has to do with it, and why memory reclamation might not be as helpful as you thought.

Asynchronous I/O, ML-based query plan optimization, and built-in connection pooling are among the key features of the new Postgres Pro Enterprise 18. This release brings together the capabilities of the vanilla PostgreSQL 18 core with Enterprise-grade tools for working with large-scale data. Today we will walk through the technical details, new index scanning strategies, and mechanisms for scaling write workloads.

Today we want to talk about choosing a DBMS for WMS not as a dry technical discussion, but as a strategic decision that determines the security, budget, and future flexibility of your business. This is not about "why PostgreSQL is technically better," but about why it has become the only safe, cost-effective, and future-proof solution for Russian warehouse systems in the new reality.

This is not just another database article. It is a roadmap for those who do not want to wake up one day with a paralyzed warehouse and multi-million fines due to a bad decision made yesterday. At INTEKEY we have gone this path deliberately, and today our WMS projects for the largest market players run on PostgreSQL. We know from experience where the pitfalls are and how to avoid them.

Bulk config rollouts, built-in OpenTelemetry, and two-click HA cluster control are all part of one goal: making PostgreSQL admin simpler and safer. PPEM 2.3 is a big step toward that — with user-defined presets, a reworked alerting system, and stronger RBAC — helping you bring order to messy configs and trust the system to warn you before things go sideways.

A common task in enterprise systems is to load large volumes of data into PostgreSQL — sometimes tens or even hundreds of millions of rows. At first glance, this seems simple: just write a loop in Java and call save() for every record. But in reality, such an approach can be painfully slow. Even a perfectly tuned PostgreSQL instance won’t help if the application is sending data inefficiently.

This article explains how to significantly accelerate bulk inserts when working with PostgreSQL through Spring and Hibernate. We’ll walk through which Spring and Hibernate settings are worth enabling, why they matter, and how much performance they can actually unlock. We’ll also look at how to build your own data-insertion layer for PostgreSQL — one that lets you switch between different insertion strategies, leverage PostgreSQL’s custom capabilities, and parallelize the process. Finally, we’ll see how to integrate this layer with Spring and what real gains each approach can deliver.