In the IT crowd, it’s common to mock HR for their weird terminology and attempts to assess a “rich inner world” instead of clean code. But when a senior starts tearing juniors apart in code reviews to the point where they end up crying in the bathroom, nobody’s laughing anymore.

We pit two archetypes against each other: the “toxic genius” and the “human glue”. Which one is dead weight, and which one is the load-bearing structure of the project? You might not like the answer.

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

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.

Some IT companies say they support open source. In practice, that often boils down to using other people’s code and a bit of PR. We believe real contribution means commits to the core. And to do that consistently, we opened an engineering center not in a glossy capital business park, but in a place where fundamental science is part of the cultural DNA. Here’s why we’re building the future of systems programming in Novosibirsk Akademgorodok.

Hitting the 4-billion-row limit in a TOAST table or running into an OidGen lock during a massive document import is a PostgreSQL admin’s nightmare. Sure, architects will tell you to push files to S3 — but real life often means keeping them inside the database. In this post, application optimization lead Alexander Popov breaks down how the standard bytea and pg_largeobject mechanisms work, where their bottlenecks hide, and how Postgres Pro Enterprise helps you get around those limits.

Throughout their careers engineers build systems that protect data and guard it against corruption. But what if the right approach is the opposite: deliberately corrupting data, generating it out of thin air, and creating forgeries indistinguishable from the real thing?

Maksim Gramin, systems analyst at Postgres Professional, explains why creating fake data is a critical skill for testing, security, and development — and how to do it properly without turning your database into a junkyard of “John Smith” entries.

Technical support comes in many shapes. Sometimes it’s "try rebooting" or "check the cable." And sometimes it’s deep engineering work you wouldn’t mind dedicating your whole life to. Which version lives inside Postgres Professional, and what’s more important in this field — people or tech? We dig into this with Kamil Karimov, Senior technical support engineer at Postgres Professional.

For businesses running 1C:Enterprise, database stability and speed aren't nice-to-haves—they're make-or-break. At Postgres Professional, we're constantly working on the DBMS core, eliminating architectural bottlenecks that show up under the heavy loads typical of 1C deployments.

We've just released Postgres Pro Enterprise 17.6 with a fresh batch of improvements specifically for 1C users.

Everyone knows great documentation makes or breaks a tech product — but few realize how much work goes into it. At Postgres Professional, the docs are written with the same discipline as the code. What’s even more impressive, all of it is done by a team of just ten people. We talked to senior technical writer Ekaterina Gololobova to see how it really works — from the first task to the final commit.

One of the open challenges in the database world is keeping a database consistent across multiple DBMS instances (nodes) that independently handle client connections. The crux of the issue is ensuring that if one node fails, the others keep running smoothly — accepting connections, committing transactions, and maintaining consistency without a hitch. Think of it like a single DBMS instance staying operational despite a faulty RAM stick or intermittent access to multiple CPU cores.

My name is Andrey Lepikhov, and I’d like to kick off a discussion about the multi-master concept in PostgreSQL: its practical value, feasibility, and the tech stack needed to make it happen. By framing the problem more narrowly, we might find a solution that’s genuinely useful for the industry.

In an era dominated by high-level abstractions and a focus on rapid development, the C programming language seems like a relic to many — an "outdated" tool with manual memory management and "dangerous" pointers. But what if these are its greatest strengths?

Maxim Orlov, a programmer at Postgres Professional with 22 years of experience, argues that C is not about quick wins and fast prototypes, but about fundamental control and a deep, philosophical understanding of how computers work. Join us for a journey from an initial frustration with Pascal to a profound appreciation for C, and learn why this "bastion of calm" is more relevant than ever.

Traditional approaches to SQL query generation often rely on instruction-tuned language models, but these can be inefficient and inaccurate. In this article, we’ll explore a new method based on reinforcement learning for model fine-tuning, which can improve both the accuracy and efficiency of SQL generation.

The “test everything” principle doesn’t improve data quality — it destroys it. Hundreds of useless alerts create noise that drowns out truly important signals, and the team stops responding to them. Google and Monzo have already moved away from this approach.

Here’s how to shift from blanket testing to targeted checks at nodes with the greatest impact radius — and why one well-placed test at the source is worth more than a hundred checks downstream.

The myth of the magical fast=true parameter is still alive and well, but in distributed databases, another contender appears: distributed=true. Neither one will save you if you don’t rethink your schema, sharding keys, sequences, queries, and migration process. We walk through every corner with a clear-eyed approach — from choosing sharding keys and colocated tables to CDC, topologies, and foreign key constraints — showing where performance really improves, where it gets more expensive, and how to deal with it.